Be sure to read our latest SSD article: The SSD Relapse for an updated look at the SSD market.

The Prelude

I spent about three weeks working on my review of Intel’s X25-M SSD. Most of that was research and writing and re-writing to not only review the product but also to talk about the rest of the SSDs in the marketplace and their deficiencies. Truth be told, I spent more time working on SSDs that weren’t the X25-M than the Intel drive itself. The Intel drive just worked as it should, the rest of them didn’t.

If you read the article, you know I was pretty harsh on some of the SSDs out at the time and if you’ve ever used any of those SSDs, you know why. Needless to say, there was some definite fallout from that review. I’m used to negative manufacturer response after a GPU review, but I’m always a bit surprised when it happens in any other segment.

I took a day or two off after that review went live, I think it was a day. Afterwards, I immediately started working on a follow-up. There was a strange phenomenon a few people noticed, something I unfortunately picked up on after the review went live; if you filled the X25-M up and re-benchmarked it, it got slower. And I had no idea why.

A few weeks later, I had it figured out. But then Nehalem was right around the corner. I’d tackle it after that. But then a new batch of SSDs from OCZ and other vendors were almost ready. I told myself I’d do them all at the same time. Then CES happened.

The More Things Change, The More They Stay The Same

If you look at the SSD market today, you’d assume that it’s very different from what it was just six months ago when the X25-M launched. People are worried that the Intel drive has issues with degrading performance over time. Some vendors are now shipping “revised” JMicron drives with multiple controllers, supposedly fixing all of the problems I talked about last year.

I hate to break it to you guys. As different as the world may seem today, it’s all very much the same.

The Intel drive is still the best of the best. Yes, it, and other SSDs do get slower over time and later in this article I’ll explain why it happens and why it’s not as big of a deal as you’d think. The issues I complained about with the JMicron drives from last year are still alive and well today; they’re just somewhat occluded.

Delay after delay kept me from writing this article, but I believe it’s for the best. What went in to what you’re about to read is nearly six months of research, testing and plain old work with SSDs.

The timing couldn’t be more perfect. We’re about to see a new wave of SSDs hit the market and it’s time to separate the fact from the fiction, the benchmarks from reality and the men from the boys. The last time I wrote an article about SSDs I ruffled quite a few feathers. That’s never my aim, but we’ll see what comes of this one.

Bringing You Up to Speed: The History Lesson
POST A COMMENT

308 Comments

View All Comments

  • tirez321 - Wednesday, March 18, 2009 - link

    I can kinda see that it wouldn't now.
    Because there would still be states there regardless.
    But if you could inform the drive that it is deleted somehow, hmm.

    Reply
  • strikeback03 - Wednesday, March 18, 2009 - link

    The subjective experiences with stuttering are more important to me than most of the test numbers. Other tests I have found of the G.Skill Titan and similar have looked pretty good, but left out mention of stuttering in use.

    Too bad, as the 80GB Intel is too small and the ~$300 for a 120GB is about the most I am willing to pay. Maybe sometime this year the OCZ Vertex or similar will get there.
    Reply
  • strikeback03 - Tuesday, March 24, 2009 - link

    When I wrote that, the Newegg price for the 120GB Vertex was near $400. Now they have it for $339 with a $30 MIR. Now that's progress. Reply
  • kamikaz1k - Wednesday, March 18, 2009 - link

    the latency times are switched...incase u wanted to kno.
    also, first post ^^ hallo!
    Reply
  • GourdFreeMan - Wednesday, March 18, 2009 - link

    It seems rather premature to assume the ATA TRIM command will significantly improve the SSD experience on the desktop. If you were to use TRIM to rewrite a nonempty physical block, you do not avoid the 2ms erase penalty when more data is written to that block later on and instead simply add the wear of another erase cycle. TRIM, then, is only useful for performance purposes when an entire 512 KiB physical block is free.

    A well designed operating system would have to keep track of both the physical and logical maps of used space on an SSD, and only issue TRIM when deletion of a logical cluster coincides with the freeing of an entire physical block. Issuing TRIMs at any other time would only hurt performance. This means the OS will have significantly fewer opportunities to issue TRIMs than you assume. Moreover, after significant usage the physical blocks will become fragmented and fewer and fewer TRIMs will be able to be issued.

    TRIM works great as long as you only deal with large files, or batches of small files contiguously created and deleted with significant temporal locality. It would greatly aid SSDs in the "used" state Anand artificially creates in this article, but on a real system where months of web browsing, Windows updates and software installing/uninstalling have occurred the effect would be less striking.

    TRIM could be mated with periodic internal (not filesystem) defragmentation to mitigate these issues, but that would significantly reduce the lifespan of the SSD...

    It seems the real solution to the SSD performance problem would be to decrease the size of the physical block... ideally to 4 KiB, as that is the most common cluster size on modern filesystems. (This assumes, of course, that the erase, read and write latencies could be scaled down linearly.)
    Reply
  • Kary - Thursday, March 19, 2009 - link

    Why use TRIM at all?!?!?

    If you have extras Blocks on the drive (NOT PAGES, FULL BLOCKS) then there is no need for TRIM command.

    1)Currently in use BLOCK is half full
    2)More than half a block needs to be written
    3)extra BLOCK is mapped into the system
    4)original/half full block is mapped out of system.. can be erased during idle time.

    You could even bind multiple continuous blocks this way (I assume that it is possible to erase simultaneously any of the internal groupings pages from Blocks on up...they probably share address lines...ex. erase 0000200 -> just erase block #200 ....erase 00002*0 -> erase block 200 to 290...btw, did addressing in base ten instead of binary just to simplify for some :)
    Reply
  • korbendallas - Wednesday, March 18, 2009 - link

    Actually i think that the Trim command is merely used for marking blocks as free. The OS doesn't know how the data is placed on the SSD, so it can't make informed decision on when to forcefully erase pages. In the same way, the SSD doesn't know anything about what files are in which blocks, so you can't defrag files internally in the drive.

    So while you can't defrag files, you CAN now defrag free space, and you can improve the wear leveling because deleted data can be ignored.

    So let's say you have 10 pages where 50% of the blocks were marked deleted using the Trim command. That means you can move the data into 5 other pages, and erase the 10 pages. The more deleted blocks there are in a page, the better a candidate for this procedure. And there isn't really a problem with doing this while the drive is idle - since you're just doing something now, that you would have to do anyway when a write command comes.
    Reply
  • GourdFreeMan - Wednesday, March 18, 2009 - link

    This is basically what I am arguing both for and against in the fourth paragraph of my original post, though I assumed it would be the OS'es responsibility, not the drive's.

    Do SSDs track dirty pages, or only dirty blocks? I don't think there is enough RAM on the controller to do the former...
    Reply
  • korbendallas - Wednesday, March 18, 2009 - link

    Well, let's take a look at how much storage we actually need. A block can be erased, contain data, or be marked as trimmed or deallocated.

    That's three different states, or two bits of information. Since each block is 4kB, a 64GB drive would have 16777216 blocks. So that's 4MB of information.

    So yeah, saving the block information is totally feasible.
    Reply
  • GourdFreeMan - Thursday, March 19, 2009 - link

    Actually the drive only needs to know if the page is in use or not, so you can cut that number in half. It can determine a partially full block that is a candidate for defragmentation by looking at whether neighboring pages are in use. By your calculation that would then be 2 MiB.

    That assumes the controller only needs to support drives of up to 64 GiB capacity, that pages are 4 KiB in size, and that the controller doesn't need to use RAM for any other purpose.

    Most consumer SSD lines go up to 256 GiB in capacity, which would bring the total RAM needed up to 8 MiB using your assumption of a 4 KiB page size.

    However, both hard drives and SSDs use 512 byte sectors. This does not necessarily mean that internal pages are therefore 512 bytes in size, but lacking any other data about internal pages sizes, let's run the numbers on that assumption. To support a 256 MiB drive with 512 byte pages, you would need 64 MiB of RAM -- which only the Intel line of SSDs has more than -- dedicated solely to this purpose.

    As I said before there are ways of getting around this RAM limitation (e.g. storing page allocation data per block, keeping only part of the page allocation table in RAM, etc.), so I don't think the technical challenge here is insurmountable. There still remains the issue of wear, however...
    Reply

Log in

Don't have an account? Sign up now