OCZ's Indilinx Everest 2 Launching in June 2012, Features Vastly Improved Random Performance

11 Comments

View All Comments

• Wardrop - Monday, January 9, 2012 - link

  I'm wondering what characteristics factor in to making an SSD fast. Are SSD's typically bottlenecked by the brute performance of the controller, the speed of the NAND, or is it more down to a good storage strategy (firmware/logic design)?

• r3loaded - Monday, January 9, 2012 - link

  All of the above! :P

• DanNeely - Monday, January 9, 2012 - link

  Nand bottlenecks are mostly a factor on smaller capacity drives. Most designs stop seeing gains with capacity before hitting their largest available size; at which point the controller hardware/firmware dominates.

• SleepyFE - Monday, January 9, 2012 - link

  Smaller capacity drvie is slower because of larger capacity NAND chips. If a single NAND chip is 16GB it takes 8 of them to make 128GB drive and each uses one channel. Since controllers have 8 channels you can reach maximum speed that way. But there are also 32GB chips, and when you make a 128GB drive out of those you only use 4 channels and that is why it is slower.

• Shadowmaster625 - Monday, January 9, 2012 - link

  It's all firmware. Look at your typical NTFS file. 40% of files are less than 4KB, meaning they fit into a single NTFS cluster. My computer has 52000+ files that are less than 4KB. That is 40% of my files. Many thousands of these files are only a few bytes, or a few hundred bytes. When you go to write this file to NAND, you need only write those bytes. A smart controller has to understand that.
  
  Then there's compression. It is stupid to not compress easily compressible data when the compression can be done faster than the writes can take place, even when done by a $2 microcontroller.
  
  And there is also the fact that most writes are partial in nature. ie, you read a file, change a few bytes, and write it back. A dumb controller will read out a 2MB file and write the whole entire thing back even though only 2 bytes have changed. Windows does this sort of crap all the time. A smart controller will be aware that this file was recently read, and it will look in its RAM to see if the file is there, do some comparions, do some data integrity checks, then write only those two new bytes to flash. Huge performance increase potential there.

• FunBunny2 - Monday, January 9, 2012 - link

  -- A smart controller will be aware that this file was recently read, and it will look in its RAM to see if the file is there, do some comparions, do some data integrity checks, then write only those two new bytes to flash. Huge performance increase potential there.
  
  Only under rare and wonderful circumstances can current NAND be written like that; an SSD doesn't write like an HDD. A controller could implement logic to identify such circumstances, but running through that logic every write request for those .001% of same which can be written this way; I wouldn't bet on it.

• FaaR - Friday, January 13, 2012 - link

  You can't write just two bytes to flash, you gotta write an entire page (and if there are no free pages you must first erase a block of pages. And due to wear leveling and such you wouldn't want to keep re-writing the same two bytes over and over if that's all that's changing in a particular file, even if that was possible...

• davele - Saturday, January 28, 2012 - link

  Re: "Windows does this sort of crap all the time" There is no free lunch with large file I/O.
  Yes; It would be much less work to just write the 2 bytes. But the minimum sector size is 512 bytes (or 4K). Writing complete sectors helps to let the electronics in the drive stabilise. (assuming a non-SSD drive) & compensates for minute fluctuations in drive speed. Any data changes also cause a need to write a checksum, so need to update the page header. Often the 2 bytes become 3 or 1 & you need to move everything. Is it really worth having special case code to handle the rare condition of changing the same number of bits. (this is not a database)
  Of course if the file was big & split into a binary tree / linked list of blocks you could just update only the block you need.
  But others prefer robustness. They feel that the changes should be written to another part of the disk & only when successful would you remove the original data.
  
  You could have a completely different algorithm for SSD vs Magnetic drives. But then you get overhead caused by adding another level of abstraction.
  
  Others have already mentioned SSD Page erase requirements.
  In short it is not as trivial as you may first think.

• SleepyFE - Monday, January 9, 2012 - link

  NAND is fast enough for the moment (since it is the smallest possible array of transistors), firmware is what makes the controller tick, so it is mostly up to the controller.

• Movieman420 - Monday, January 9, 2012 - link

  SF-like performance with both compressible and incompressible data both...that's a total win-win situation!