The SSD Relapse: Understanding and Choosing the Best SSD
by Anand Lal Shimpi on August 30, 2009 12:00 AM EST- Posted in
- Storage
Live Long and Prosper: The Logical Page
Computers are all about abstraction. In the early days of computing you had to write assembly code to get your hardware to do anything. Programming languages like C and C++ created a layer of abstraction between the programmer and the hardware, simplifying the development process. The key word there is simplification. You can be more efficient writing directly for the hardware, but it’s far simpler (and much more manageable) to write high level code and let a compiler optimize it.
The same principles apply within SSDs.
The smallest writable location in NAND flash is a page; that doesn’t mean that it’s the largest size a controller can choose to write. Today I’d like to introduce the concept of a logical page, an abstraction of a physical page in NAND flash.
Confused? Let’s start with a (hopefully, I'm no artist) helpful diagram:
On one side of the fence we have how the software views storage: as a long list of logical block addresses. It’s a bit more complicated than that since a traditional hard drive is faster at certain LBAs than others but to keep things simple we’ll ignore that.
On the other side we have how NAND flash stores data, in groups of cells called pages. These days a 4KB page size is common.
In reality there’s no fence that separates the two, rather a lot of logic, several busses and eventually the SSD controller. The latter determines how the LBAs map to the NAND flash pages.
The most straightforward way for the controller to write to flash is by writing in pages. In that case the logical page size would equal the physical page size.
Unfortunately, there’s a huge downside to this approach: tracking overhead. If your logical page size is 4KB then an 80GB drive will have no less than twenty million logical pages to keep track of (20,971,520 to be exact). You need a fast controller to sort through and deal with that many pages, a lot of storage to keep tables in and larger caches/buffers.
The benefit of this approach however is very high 4KB write performance. If the majority of your writes are 4KB in size, this approach will yield the best performance.
If you don’t have the expertise, time or support structure to make a big honkin controller that can handle page level mapping, you go to a larger logical page size. One such example would involve making your logical page equal to an erase block (128 x 4KB pages). This significantly reduces the number of pages you need to track and optimize around; instead of 20.9 million entries, you now have approximately 163 thousand. All of your controller’s internal structures shrink in size and you don’t need as powerful of a microprocessor inside the controller.
The benefit of this approach is very high large file sequential write performance. If you’re streaming large chunks of data, having big logical pages will be optimal. You’ll find that most flash controllers that come from the digital camera space are optimized for this sort of access pattern where you’re writing 2MB - 12MB images all the time.
Unfortunately, the sequential write performance comes at the expense of poor small file write speed. Remember that writing to MLC NAND flash already takes 3x as long as reading, but writing small files when your controller needs large ones worsens the penalty. If you want to write an 8KB file, the controller will need to write 512KB (in this case) of data since that’s the smallest size it knows to write. Write amplification goes up considerably.
Remember the first OCZ Vertex drive based on the Indilinx Barefoot controller? Its logical page size was equal to a 512KB block. OCZ asked for a firmware that enabled page level mapping and Indilinx responded. The result was much improved 4KB write performance:
| Iometer 4KB Random Writes, IOqueue=1, 8GB sector space | Logical Block Size = 128 pages | Logical Block Size = 1 Page |
| Pre-Release OCZ Vertex | 0.08 MB/s | 8.2 MB/s |
Facebook
Twitter
RSS
295 Comments
View All Comments
Anand Lal Shimpi - Monday, August 31, 2009 - link
I believe OCZ cut prices to distributors that day, but the retail prices will take time to fall. Once you see X25-M G2s in stock then I'd expect to see the Indilinx drives fall in price. Resellers won't give you a break unless they have to :)Take care,
Anand
bobjones32 - Monday, August 31, 2009 - link
Another great AnandTech article, thanks for the read.Just a head's-up on the 80GB X-25m Gen2 - A day before Newegg finally had them on sale, they bumped their price listing from $230 to $250. They sold at $250 for about 2 hours last Friday, went back out of stock until next week, and bumped the price again from $250 to $280.
So....plain supply vs. demand is driving the price of the G2 roughly $50 higher than it was listed at a week ago. I have a feeling that if you wait a week or two, or shop around a bit, you'll easily find them selling elsewhere for the $230 price they were originally going for.
AbRASiON - Monday, August 31, 2009 - link
Correct, Newegg has gouged the 80gb from 229 to 279 and the 160gb from 449 to 499 :(Stan Zaske - Monday, August 31, 2009 - link
Absolutely first rate article Anand and I thoroughly enjoyed reading it. Get some rest dude! LOLJaramin - Monday, August 31, 2009 - link
I'm wondering, if I were to use a low capacity SSD to install my OS on, but install my programs to a HDD for space reasons, just how much would that spoil the SSD advantage? All OS reads an writes would still be on the SSD, and the paging file would also be there. I'm very curious about the amount of degradation one would see relative to different use routines and apps.Anand Lal Shimpi - Monday, August 31, 2009 - link
Putting all of your apps (especially frequently used ones) off of your SSD would defeat the purpose of an SSD. You'd be missing out on the ultra-fast app launch times.Pick a good SSD and you won't have to worry too much about performance degradation. As long as you don't stick it into a database server :)
Take care,
Anand
swedishchef - Tuesday, September 1, 2009 - link
What if you just put your photoshop cache on a pair of Velociraptors? Would it be the same loss of benefit?I have the same question regarding uncompressed HD video work, where I need write speeds well over the Intel x25-m ( over 240Mb/s). My assumption would be that I could enjoy the fast IO and App. launch of an SSD and increase CPU performance with the SSD while keeping the files on a fast external or internal raid configuration.
Thank you again for a a brilliant Article Anand.
I have been waiting for it for a long time. Yours are the only calm words out on the net.
Grateful Geek /Also professional image creator.
creathir - Monday, August 31, 2009 - link
Great article Anand. I've been waiting for it...My only thoughts are, why can't Intel get their act together with the sequential business? Why can the others handle it, but they can't? To have such an awesome piece of hardware have such a nasty blemish is strange to me, especially on a Gen-2 product.
I suppose there is some technical reason as to why, but it needs to be addressed.
- Creathir
Anand Lal Shimpi - Monday, August 31, 2009 - link
If Intel would only let me do a deep dive on their controller I'd be able to tell you :) There's more I'd like to say but I can't yet unfortunately.Take care,
Anand
shotage - Monday, August 31, 2009 - link
Awesome article!I'm intrigued with the cap on the sequential reads that Intel has on the G2 drives as well. I always thought it was strange to see even on their first gen stuff.
I'm assuming that this cap might be in place to somehow ensure the excellent performance they are giving with random read/writes. All until TRIM finally shows up and you'll have to write up another full on review (which I eagerly await!).
I can't wait to see what 2010 brings to the table. What with the next version of SATA and TRIM just over the horizon, I could finally get the kind of performance out of my PC that I want!!