Still only relevant if somehow you are only using a single 4kb page. That's why there are tests for queue depth. The only real weakness would be if you had a limited amount of ram where you were actually running pages directly from the disk or page file and they happened to be shared pages between multiple programs or processes. But with the current availability of RAM and how small most shared pages actually are, that should be an easily avoidable issue.
Sure, there are performance increases to be had in single 4k thread performance, but I would much prefer a drive that can hit 500+MB/s at a high queue depth (4-16+) and only manages 20-30 for a single 4k block than a drive than does 100MB/s for a single 4k thread, but can only hit 200MB/s for larger queue depths.
Now I understand that with SSDs and most general uses, you rarely will exceed a QD of like 5-10. But when your queue is shorter than that, you don't really NEED that speed. The reason I say this is that 1 4k read is 4096 bytes.
4096 bytes = 0.00390625MB
My 840 Pro under a SINGLE 4k thread manages about:
30MB/s = 0.03MB per millisecond
This means that if the drive is under such a load that it NEVER processes more than one block at a time it can still do:
10 IO/ms or 7680IOPS
Now admittedly 1 MS is a very long time for a CPU, but it is imperceptible to your or me. Regardless, it has nothing to do with why an SSD seems so fast. A HDD can do a 4K transfer (NOT READs) just as fast (if not faster) as an SSD. What makes an HDD so slow is Seek Time, and it's inability perform more than 1 read at a time without a huge performance hit. If you are using an HDD, and you try to read 2 files that are in different parts of the drive at once, it has 2 options, it can either alternate between the two file locations which is horrible for performance as a seek is required every time, or you can just do them in sequence with a seek in the middle. Now which is done is largely dependent on priority and filesize, but neither is a good option.
The real problem comes with multi tasking. Say you are hosting a file server on your machine and someone in another room is streaming a bluray iso off your drive. Then you decide you want to play a game on the same drive. In theory an operating system could be designed in such a way that it would never affect an ongoing read operation, but that's not the case, so rather than waiting for the video to finish its latest buffer session, it's going to immediately seek the drive and while the gaps in seeking wouldn't be hugely detrimental to the random reads for your game (other than just making it load slower) it would cause a very clear and obnoxious impact to the playback of the video that is being streamed.
An SSD doesn't have this problem. From what I understand an SSD is essentially a tiny raid array across 8-16 DIMMs. There are 2 ways this improves performance, the first is that if the files in question are located on different DIMMs they can be read at the same time. The second is that if they happen to both be present on the same DIMM, it can alternate between reads for the 2 files with no seek time in the middle, so rather than waiting milliseconds to alternate block to block, you are simply halving your random access read time between 2 operations.
This is where your controller and firmware become extremely important. Since at least in theory, they should be balancing commonly accessed blocks across your NAND, so that you don't end up with 20 reads on 1 NAND and 15 inactive ones. Essentially the Controller is there to cover up the limited speed of a single DIMM's read.
The biggest benefit of significantly increasing single thread 4k speed would be improved endurance of a drive as there would be less need to load balance it.
I do think eventually as NAND prices come down and single die sizes increase, we will start to see SSDs that are built more like RAID 10 than RAID 0, but that's largely irrelevant for now.
Edited by Amnesia1187 - 12/26/12 at 5:48am