The SSD Anthology: Understanding SSDs and New Drives from OCZ
by Anand Lal Shimpi on March 18, 2009 12:00 AM EST- Posted in
- Storage
Latency vs. Bandwidth: What to Look for in a SSD
It took me months to get my head wrapped around it, but I think I finally get it. We often talk about the concepts of bandwidth and latency but rarely are they as tangible as they are here today.
When I speak of latency I’m talking about how long it takes to complete a request, or fetch a block of data. When I mention bandwidth, I’m talking about how much you can read/write at once. Think of latency as the speed limit and bandwidth as the number of lanes on a high way.
If you’re the only car on the highway, you’re going to notice the impact of latency more than bandwidth. A speed limit of 70 mph instead of 35 is going to impact you much more than if you added more lanes to the road.
If you’re a city planner however and your only concern is getting as many people to work and back, you’re going to notice the impact of bandwidth more than latency. It doesn’t matter how fast a single car can move, what matters is how many cars you can move during rush hour traffic.
I’d argue that if you’re a desktop user and you’re using an SSD as a boot/application drive, what will matter most is latency. After you’ve got your machine setup the way you want it, the majority of accesses are going to be sequential reads and random reads/writes of very small file sizes. Things like updating file tables, scanning individual files for viruses, writing your web browser cache. What influences these tasks is latency, not bandwidth.
If you were constantly moving large multi-gigabyte files to and from your disk then total bandwidth would be more important. SSDs are still fairly limited in size and I don’t think you’ll be backing up many Blu-ray discs to them given their high cost per GB. It’s latency that matters here.
Obviously I’ll be testing both latency and bandwidth, but I wanted to spend a moment talking about the synthetic latency tests.
Iometer is a tool that can simulate any combination of disk accesses you can think of. If you know how an application or OS hits the disk, iometer can simulate it. While random disk accesses are the reason that desktop/notebook hard drives feel so slow, the accesses are generally confined to particular areas of the disk. For example, when you’re writing a file the OS needs to update a table mapping the file you’re writing to the LBAs it allocated for the file. The table that contains all of the LBA mapping is most likely located far away from the file you’re writing, thus the process of writing files to the same area can look like random writes to two different groups of LBAs. But the accesses aren’t spread out across the entire drive.
In my original X25-M article I ran a 4KB random write test over the entire span of the drive. That’s a bit more ridiculous than even the toughest user will be on his/her desktop. For this article I’m limiting the random write test to an 8GB space of the drive; it makes the benchmark a little more realistic for a desktop/notebook workload.
The other thing I’ve done is increased the number of outstanding IOs from 1 to 3. I’ve found that in a multitasking user environment Vista will generally have a maximum of 3 or 4 outstanding IOs (read/write requests).
The combination of the two results in a 100% random file write of 4KB files with 3 outstanding IOs to an 8GB portion of the drive for 3 minutes. That should be enough time to get a general idea of how well these drives will perform when it comes to random file write latency in a worst case, but realistic usage scenario.
Facebook
Twitter
RSS
250 Comments
View All Comments
SunSetSupaNova - Wednesday, March 18, 2009 - link
Just wanted to say great job Anand on a great article, it took me a while to read it from start to finish but it was well worth it!FHDelux - Wednesday, March 18, 2009 - link
That was the best review i have read in a long time. I originally bought an OCZ Core drive when they first came out. It was the worst piece of garbage i had ever used. Newegg wouldn't let me send it back and OCZ support forums told me all sorts of junk to get me to fix it but it was just a poorly designed drive. I eventually ended up getting the egg to take it back for credit and i wrote OCZ off as a company blinded by the marketing department. I currently own an Intel SSD and its wonderfull, everytime i see OCZ statements saying their drive competes with the Intel drive i would laugh and think back to the OCZ techs telling me i need to update my bios, or i need to install vista service pack 1 before it would work right.I am thankful that you slapped that OCZ big wig around until they made a good product. All of us out there that wasted our time and money on Pre-vertex generation drives are greatfull to you and the whole industry should be kissing your butt right now.
One thing these companies need to learn is that marketing isn't the answer, creating solid products is. Hopefully OCZ has learned their lesson, and because of your article i will give them another chance.
THANK YOU!
kelstertx - Wednesday, March 18, 2009 - link
I didn't want to worry about eventual failure of the Flash chips of an SSD, and went with an SDRAM based Ramdrive from Acard. These drives have no latency of any kind, since they use SDRAM, and no lifespan of write cycles. I've been using mine for a couple of weeks now, and I like it a lot. I put Ubuntu on mine, and had 2G left for my small home folder. The standard HDD is my long-term storage for data files, music, etc. As SDRAM gets more affordable over time, I can add DIMMs and bump up the size.I know this review was about SSDs strictly, so an SDRAM drive doesn't technically fit, but it would have been interesting to see a 9010 or 9010b in there for comparison. It beat the Intel SSD in almost all the tests. http://techreport.com/articles.x/16255/1">http://techreport.com/articles.x/16255/1
7Enigma - Wednesday, March 18, 2009 - link
I've been eying these guys ever since the announced their first press release. Every time I always was drawn away by the constant need for power (4h max on battery scares the bejeezus out of me if I was to be gone on vacation during a storm), high power usage at all times, and high cost of entry (after factoring in all of the ram modules).I really dislike that article as well, since I think the bottlenecks were much less apparent with such a horribly slow cpu. The majority of that review's data is extremely compressed. I mean a P4, and 1 gig of memory; are you F'ing kidding me? This article was written in Jan of this year!? Why didn't they just use my old 486DX?
tirez321 - Wednesday, March 18, 2009 - link
What would a drive zeroing tool do to write performance, like if you used acronis privacy expert to zero only the "free space" regularly? Would it help write performance due to the drive not having to erase pages before writing?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.
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.
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.kamikaz1k - Wednesday, March 18, 2009 - link
the latency times are switched...incase u wanted to kno.also, first post ^^ hallo!
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.)