Random Read/Write Speed

The four corners of SSD performance are as follows: random read, random write, sequential read and sequential write speed. Random accesses are generally small in size, while sequential accesses tend to be larger and thus we have the four Iometer tests we use in all of our reviews.

Our first test writes 4KB in a completely random pattern over an 8GB space of the drive to simulate the sort of random access that you'd see on an OS drive (even this is more stressful than a normal desktop user would see). We perform three concurrent IOs and run the test for 3 minutes. The results reported are in average MB/s over the entire time.

Desktop Iometer - 4KB Random Read

Desktop Iometer - 4KB Random Write

Desktop Iometer - 4KB Random Write (QD=32)

Random performance is similar to the Extreme Pro except for high queue depth write. Most client/corporate workloads do not go above queue depth of 5 anyway, so that should not be a problem.

Sequential Read/Write Speed

To measure sequential performance we run a 1 minute long 128KB sequential test over the entire span of the drive at a queue depth of 1. The results reported are in average MB/s over the entire test length.

Desktop Iometer - 128KB Sequential Read

Sequential read performance is excellent and sequential write is okay too, making the X300s equivalent to the Extreme Pro.

Desktop Iometer - 128KB Sequential Write

 

AS-SSD Incompressible Sequential Read/Write Performance

The AS-SSD sequential benchmark uses incompressible data for all of its transfers. The result is a pretty big reduction in sequential write speed on SandForce based controllers, but most other controllers are unaffected.

Incompressible Sequential Read Performance

Incompressible Sequential Write Performance

AnandTech Storage Bench 2011 Performance vs. Transfer Size
Comments Locked

34 Comments

View All Comments

  • hojnikb - Friday, August 22, 2014 - link

    *at a cost of capacity :) :)
  • Kristian Vättö - Friday, August 22, 2014 - link

    Yeah, fundamentally SLC, MLC and TLC are the same. Of course there are some silicon level optimizations to better fit the characteristics of each technology but the underlaying physics are the same.

    I'm thinking that pseudo-SLC is effectively just combining the voltage states of MLC/TLC. I.e. output of 11 or 10 from the NAND would read as 1, which allows for higher endurance since it doesn't matter if the actual voltage state switches from 11 to 10 due to the oxide wear out.
  • Spoony - Friday, August 22, 2014 - link

    I believe you'd lose half the capacity on your drive. The MLC drives store two bits per cell, so they would store a 1 and a 0 for example. If you now are only allowing it to store a 1, then you've halved the capacity of the cell. Across the entire drive, this would thus halve the total drive capacity.

    As far as performance (read/write speed) I think this would be affected less. SSDs rely on parallelism to extract performance from NAND. The array is just as parallel as before. There might be an impact to performance having to do with extracting less information from each cell, how much this would be I'm not sure.

    I think the changes to firmware would have to be much more substantial than just re-programming how many bits per cell are stored. There is most likely a lot of interesting logic around voltage handling at very small scales. Perhaps even looking at how voltages from neighbouring cells influence each other. I'm not sure how serious this firmware gets regarding physics, but it must have to do some sort of compensation because the drives seem pretty reliable.
  • hojnikb - Friday, August 22, 2014 - link

    Yeah, ive "edited" the post to reflect the loss of capacity. Obviously capacity drops, but its still waay cheaper than real SLC solutions.

    I bet write speeds would actually go up (since this is the exact reason why samsung and sandisk are doing pSLC) but read would stay unaffected (since this is controller/interface limited anyway).
  • BillyONeal - Thursday, August 21, 2014 - link


    eDrive is not really designed for big corporate operations as it lacks the tools for remote management

    Erm, what is MBAM for then? http://technet.microsoft.com/en-us/library/hh82607... My work PC has remotely managed BitLocker.
  • Zink - Thursday, August 21, 2014 - link

    MBAM is "Malwarebytes Anti-Malware" malware removal tool
  • BillyONeal - Thursday, August 21, 2014 - link

    @Zink: It is also "Microsoft Bitlocker Administration and Management"
  • Kristian Vättö - Thursday, August 21, 2014 - link

    Looks like I should have done my research better. Thanks for the heads up, I've edited the review to remove the incorrect reference.
  • thecoolnessrune - Thursday, August 21, 2014 - link

    Yep, I the company I work with also has all of our drives encrypted with Bitlocker. It's managed by MBAM and integrated right into the rest of Active Directory Management. Really simple for the Domain Administrators (and relevant IT HelpDesk personnel) to use and manage.

    eDrive can fit in the Enterprise environment quite well.
  • cbf - Thursday, August 21, 2014 - link

    Yup. As the other commenters indicate, the only thing we care about in the Enterprise is BitLocker. Hell, even if it was my personal drive, I'd probably only use BitLocker. I just trust it more than the third party solutions.

    So why don't you review this drive's encryption features using BitLocker. Anand showed how to do this last April: http://www.anandtech.com/show/6891/hardware-accele...

Log in

Don't have an account? Sign up now