Sign in to follow this  
doctorj

Why aren't SSDs significantly faster than mechanical drives?

Recommended Posts

I'd like to know what really limits the performance of desktop applications. It is conventional wisdom that they are "I/O limited," i.e., waiting for the hard disk. And this in turn is because of the large seek times involved in random I/O.

Then, SSDs come along and reduce seek time by a factor of 100 -- and performance goes up only a few percent.

If seek times are really the bottleneck, why don't we see desktop apps with instantaneous response on an SSD? Why are they only marginally faster?

Here are some guesses:

  • Most mechanical drive requests are serviced from the buffer?
  • Operating systems' I/O strategies are tuned for mechanical drives?
  • Sequential transfer rate is actually the bottleneck?
  • File systems and storage layouts are optimized for mechanical drives?
  • Performance is limited by I/O transaction overhead?

Speculation is nice, but I'd prefer answers backed up by real data.

Share this post


Link to post
Share on other sites

Aren't you putting too much emphasis on the seek times? Read and write performance is important, and flash SSDs are limited by the speed of the flash chips that are used, so the reason flash SSDs are the speed they are is because flash memory is only that fast right now!

Share this post


Link to post
Share on other sites

It's not just seek times, but what the drive does when it comes to the cells after it addresses them. Hence why flash drives tend to be horrorific on random writes even when spec'ed at 100MB/sec or whatnot.

Share this post


Link to post
Share on other sites
Guest Eugene
[*]Most mechanical drive requests are serviced from the buffer?

Speculation is nice, but I'd prefer answers backed up by real data.

That's the main reason right there. Depending on applications, between 25% and 80% of data is either fetched from the buffer on a good SATA drive (the figure is much less on the typical SAS drive which is the primary reason why SATA drives whip SAS units for non-server use) or the next request lies very close to the previous fetch when it comes to "stride," the LBA distance between two transactions. Low stride distances that aren't mitigated outright by the drive's buffer are usually served from the same track, more often than not just a few sectors away:

For some data, check out the "Distribution of seek distances" graph and the writeup below it at http://www.storagereview.com/Testbed4.sr?page=0%2C2

Regarding the relevance of seek times in general to today's applications, this older data-heavy thread is still quite relevant: http://forums.storagereview.net/index.php?...mp;#entry217603

Share this post


Link to post
Share on other sites

Applications avoid random IO like the plague. Sequential IO is so much faster than random IO that it's almost always worth it to change your access pattern even if that means introducing a lot of overhead.

Even with an SSD, Random IO still has penalties because the rest of the IO stack is still designed around long latency and big requests. Current SSDs are basically retrofits so that we can replace our HDDs. You won't see the full potential of solid state storage until we have a complete IO stack for it.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this