![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
So here's a crackpot idea of the day, courtesy of Tom's Hardware: Short-stroking to improve apparent hard drive speed. The idea is simple: hard disks contain moving parts. As we can see from a simple bandwidth vs location plot, the beginning of the disk has the highest transfer speeds because angular velocity is kept constant but bit density is much higher at the outer edge. If we constrain ourselves to using the outer edge of the drive, all the data will be geometrically closer, thereby decreasing the average and maximum seek times as well! At least that's the theory.
For today's testing, we have three disks: a Seagate ST3250310NS (7200RPM 250G SATA), a Western Digital Raptor 740GD (10000RPM 73G SATA), and a Seagate Saavio 15k.1 (15000RPM 73G SAS). Can we make the 250G disk as fast as either of the 73G disks? (HA HA HA HA)
First, let's do some random seeks on the full 250G SATA disk:
Now let's constrain our seeks to the first 73G of the 250G disk:
Hm. Well, that's about a 25% decrease (12ms to 9ms) in average seek time. Not bad.
Does that match the Raptor?
No, though it's close.
Or the Saavio?
NO.
Or the Intel 80G SSD? (HAHAAHAA)
Denied.
So as we can see, this short-stroking business is indeed useful for making your disks go faster, provided you don't mind losing 70% of the capacity. With hard disks coming in 2TB varieties this isn't terrible, but perhaps we can do better?
Yes, we can do better. If your computer watches disk activity and defragments the filesystem in such a way as to put the most used disk blocks at the beginning of the drive, then you can get (a diluted version of) the short-stroke benefits without sacrificing capacity. OSX does this with the hot file cache in HFS+ and Win98 did it with FAT32 (though FAT32 is such a terrible filesystem that it probably didn't make any difference). It has been discussed by Linux developers but so far nobody does it. Whether that's because nobody's convinced it's worth the trouble or because they fear the MS patents, I don't know.
[Update 17:05] Next question: Which matters more? Seek distance or seek target? From these results it would seem that the destination doesn't really matter much, though the end of the disk seeks somewhat more slowly. On the other hand, the transfer speed at the end is significantly lower, so the end of the disk is still the slowest part.
[Update 17:41] I put all the disks on a single graph. Clearly the 7200RPM disks can't match the 73G Raptor. However, the price of a Raptor and the 750G disk are about the same (in Google Products), which means that if someone tells you they need to store 75GB on a fast disk, you can buy a 750G disk and let them use the first 10%, keeping the last 90% for yourself.
(Obviously if you really need speed then you pay through the nose for the 15k drive or the SSD.)
[Update weeks later] Maybe I should also post links to the bandwidth graphs. This is for the 250G SATA disk and this is for the 73G 15k disk. As you can see, the big 250G disk has comparable transfer speeds too.
For today's testing, we have three disks: a Seagate ST3250310NS (7200RPM 250G SATA), a Western Digital Raptor 740GD (10000RPM 73G SATA), and a Seagate Saavio 15k.1 (15000RPM 73G SAS). Can we make the 250G disk as fast as either of the 73G disks? (HA HA HA HA)
First, let's do some random seeks on the full 250G SATA disk:
Now let's constrain our seeks to the first 73G of the 250G disk:
Hm. Well, that's about a 25% decrease (12ms to 9ms) in average seek time. Not bad.
Does that match the Raptor?
No, though it's close.
Or the Saavio?
NO.
Or the Intel 80G SSD? (HAHAAHAA)
Denied.
So as we can see, this short-stroking business is indeed useful for making your disks go faster, provided you don't mind losing 70% of the capacity. With hard disks coming in 2TB varieties this isn't terrible, but perhaps we can do better?
Yes, we can do better. If your computer watches disk activity and defragments the filesystem in such a way as to put the most used disk blocks at the beginning of the drive, then you can get (a diluted version of) the short-stroke benefits without sacrificing capacity. OSX does this with the hot file cache in HFS+ and Win98 did it with FAT32 (though FAT32 is such a terrible filesystem that it probably didn't make any difference). It has been discussed by Linux developers but so far nobody does it. Whether that's because nobody's convinced it's worth the trouble or because they fear the MS patents, I don't know.
[Update 17:05] Next question: Which matters more? Seek distance or seek target? From these results it would seem that the destination doesn't really matter much, though the end of the disk seeks somewhat more slowly. On the other hand, the transfer speed at the end is significantly lower, so the end of the disk is still the slowest part.
[Update 17:41] I put all the disks on a single graph. Clearly the 7200RPM disks can't match the 73G Raptor. However, the price of a Raptor and the 750G disk are about the same (in Google Products), which means that if someone tells you they need to store 75GB on a fast disk, you can buy a 750G disk and let them use the first 10%, keeping the last 90% for yourself.
(Obviously if you really need speed then you pay through the nose for the 15k drive or the SSD.)
[Update weeks later] Maybe I should also post links to the bandwidth graphs. This is for the 250G SATA disk and this is for the 73G 15k disk. As you can see, the big 250G disk has comparable transfer speeds too.
