SSD Aging: Read Speed is Largely Unaffected

Given the nature of the SSD performance-over-time “problem” you’d expect to only pay the performance penalty when writing files, not reading. And for once, I don’t have any weird exceptions to talk about - this is generally the case.

The table below shows sequential read performance for 2MB blocks on new vs. “used” SSDs. I even included data for a couple of the hard drives in the "Used" column; for those numbers I'm simply measuring transfer rates from the slowest parts of the platter:

2MB Sequential Read Speed New "Used"
Intel X25-E   240.1 MB/s
Intel X25-M 264.1 MB/s 230.2 MB/s
JMicron JMF602B MLC 134.7 MB/s 134.7 MB/s
JMicron JMF602Bx2 MLC 164.1 MB/s 164.1 MB/s
OCZ Summit 248.6 MB/s 208.6 MB/s
OCZ Vertex 257.8 MB/s 250.1 MB/s
Samsung SLC   101.4 MB/s
Seagate Momentus 5400.6 77.9 MB/s -
Western Digital Caviar SE16 104.6 MB/s 54.3 MB/s
Western Digital VelociRaptor 118.0 MB/s 79.2 MB/s

 

The best SSDs still transfer data at over 2x the rate of the VelociRaptor.

Read latency is also extremely good on these worn SSDs:

I left the conventional hard drives out of the chart simply because they completely screw up the scale. The VelociRaptor has a latency of 7.2ms in this iometer test with a queue depth of 3 IOs; that's an order of magnitude slower than the slowest SSD here.

Since you only pay the overhead penalty when you go to write to a previously-written block, the performance degradation only really occurs when you’re writing - not when you’re reading.

Now your OS is always writing to your drive, and that’s why we see a performance impact even if you’re just launching applications and opening files and such, but the penalty is much less tangible when it comes to read performance.

New vs Used SSD Performance The Verdict
POST A COMMENT

245 Comments

View All Comments

  • Spoelie - Wednesday, March 18, 2009 - link

    third page, first table, first column: SSD and HDD entries are switched Reply
  • mikaela - Tuesday, March 16, 2010 - link

    yeah great info. also great resource Reply
  • Spoelie - Wednesday, March 18, 2009 - link

    page 19: I’d never reviewed it
    'd & -ed?
    Reply
  • HolyFire - Wednesday, March 18, 2009 - link

    "I'd never reviewed it" is correct. "I'd" here means "I had", it's Past Perfect tense. Reply
  • FishTankX - Wednesday, March 18, 2009 - link

    That should have bolded "too" Reply
  • FishTankX - Wednesday, March 18, 2009 - link

    Also, I think the velociraptor vs X-25 figures are swapped. 6 odd ms for the intel drive and 0.11ms for the velociraptor.. Reply
  • Natfly - Wednesday, March 18, 2009 - link

    Reply
  • DangerMouse4269 - Tuesday, April 13, 2010 - link

    Nicely written. Even a very out of practice Comp Eng understood that. Reply
  • geekforhire - Monday, June 14, 2010 - link

    I have just replaced the hard drive in this 3 year old Dell Inspiron 9400 notebook computer with a new and very quick OCZ SSD, manually configured the partition with a 1024 offset, freshly installed the OS, freshly downloaded all of the latest and greatest drivers from Dell, and applied all currently available OS updates from Msft.

    The problem is that when the machine resumes from Standby, it will /reliably/ (4 out of 4 attempts) produce a BSOD 0xF4 after the power button is pressed to resume the machine from standby.

    Here's the sequence to recreate the problem:

    0) Machine is booted normally into Windows, and log in to an account which has administrative privs.
    1) Click on Start -> Shut Down -> Standby.
    2) See display turn black, disk I/O light flashes then stops, then the power indicator light begins to flash on and off slowly.
    3) Wait until the power light has made 2 slow flashes.
    4) Press the power button.
    5) See the Dell Bios splash screen, then disappear
    6) Boom: See the BSOD 0xF4

    The values reported after the STOP are:
    (0x00000003, 0x865b3020, 0x865b3194, 0x805d2954)

    Note that I've been in contact with OCZ before about this SSD+computer, because the previous BSOD that was produced was 0x77. Their recommendation was to create the partition with an offset with a 64 interval, and to reflash the SSD with their modern firmware. This was done, the OS was reinstalled as described, and now I'm getting a different BSOD code. Another mention was a question whether the notebook computer uses a SATA2 controller (definitely compatible) or SATA1 (which may have troubles).

    I've run Spinrite on the SSD, and there are lots of ECC errors being reported. I've been in contact with Spinrite, and they chalk this up to the SSD being chatty (which they like), but since SSD's are new and magnetic disks are common, they want to stay focussed on magnetic disks.

    When the machine boots back up, the OS reports that a serious error has occurred, and asks that a problem report be submitted, which I do. Then an attractive but somewhat generic page is displayed with common causes (Aging or failing hard disks, large file transfers from secondary media to local hd, loss of power to a hard drive, hard disk intensive processes (eg: antivirus scanners), recently installed hardware that might have compatibility and performance problems)

    Has anyone else encountered this kind of problem, and do you have any suggestions?
    Reply
  • angavar - Thursday, September 09, 2010 - link

    As a medical student I can appreciate a well researched and analytical article when I see it. This is by far the best computer hardware review I have ever read! Thank-you for your time and effort in producing what is clearly a thoroughly researched and detailed analysis. Reply

Log in

Don't have an account? Sign up now