35GB Partition 0.31ms seek 75mb/s+ Read/Write SSD Eat your Heart Out

[Futur]

"This is a trick I use that works amazingly well.

grab a $365 1TB WD HDD, one of those low power units.

partition the first 35GB as C Drive

Partition the rest as say D drive.

The first 4% (35GB) of that 1TB drive will have an average seek time of .31ms (A Raptor is 12 times slower than that) and a transer rate of 75MB/sec. Apart from a flash drive there is nothing that can touch that, especially in regards to seek time and trust me that is where the delay always is.

cheers..."

I quote this from a guy on another forum, not sure if he posts here or not. Anyway is this true? I haven't been able to get in contact with him and all I can find is this.

I can't find any benchmarks on the net for someone who has done this and run HDTach or another benchmark tool on this small partition at the beginning of the drive.

If its true, you could get blazing performance with the seek of a SSD in windows with massive read/write and still have massive space left over for backup and storage. The theory behind it makes sense but i'm not convinced yet to go and buy a 1TB drive to try it.

So has anyone had any experience with this or is this guy just pulling our legs and figures out of thin air?


I found this link that mentions it slightly, but it's very dated.
http://partition.radified.com/partitioning_2.htm

 

[choirbass]

its true what he said, the same partitioning benefits also apply to every other mechanical hdd, you need to take the track to track seek times and platter density into consideration. so a 5 platter 200GB hdd will be slower than a 3 platter 334GB hdd, even though theyre both 1TB in capacity.

for example, if its .31ms from track to track, and each track is 35GB in size, then it works out... ive done the same type of partitioning on my 74GB ADFD raptor, having several 10-25GB partitions... much smaller than that though is too small, imo.

 

[Futur]

its true what he said, the same partitioning benefits also apply to every other mechanical hdd, you need to take the track to track seek times and platter density into consideration. so a 5 platter 200GB hdd will be slower than a 3 platter 334GB hdd, even though theyre both 1TB in capacity.

for example, if its .31ms from track to track, and each track is 35GB in size, then it works out... ive done the same type of partitioning on my 74GB ADFD raptor, having several 10-25GB partitions... much smaller than that though is too small, imo.

Really? Have you seen anyone do this and got benchmarks to back it up? So the Samsung Spinpoint would be a better drive to do this on because its 3 platter compared to say the Western Digital which is 5 and they are both 1TB? Thanks for the reply btw! My first post

 

[tvh]

Ok now you have my attention. I am very interested an eager to do this when I get a computer. Would it be possible to do it on a WD caviar 500GB AAKS drive? to get fast response time what would teh partitions be?

 

[choirbass]

well, take the F1 spinpoint that was just released which, if you partition the first 35GB of its 334GB platter, it will be a consistant 116-118MB/s for both reads and writes, since the heads wont need to move outside of that first 35GB barrier to do anything... unless you intentionally access data on another portion of the hdd at the same time, which would effectively reduce performance for both partitions.

http://shopper.cnet.com/hard-drives/samsung-spinpoint-f1-hd103uj/4014-3186_9-32733943.html

reading the specs, it says it would take 20ms to read from one end of platter, all the way to the other end, assuming no stops inbetween. each track takes 0.8ms to read across. so 20ms/0.8ms=25 tracks @ 0.8ms each.
1000GB/25tracks=40GB per track @ 0.8ms each.

if you wanted to do 0.31ms access times, you would need about 15GB for the partition, and thats with a huge 334GB platter too. so a smaller 200GB platter @ 7200rpms would be even worse off for general performance (due to the transfer rates per track being noticably lower, eg 75MB/s and 118MB/s).

this is effectively full stroking, half stroking, quarter stroking, etc, depending on how much of the hdd is being used for a partition that the heads would need to move across. so a partition half the size of the hdd would be half stroked.

using the same math, if you were to partition a 74GB ADFD raptor which has 74GB platters, its listed as 84MB/s max.
it says it would take 10.2ms to read from one end of the platter, all the way to the other end, assuming no stops inbetween. each track takes 0.4ms to read across. so 10.2ms/0.4ms=25.5 tracks @ 0.4ms each.
74GB/25.5tracks=2.9GB per track @ 0.4ms each

so for partitioning for performance reasons, it would seem better to get a 150GB raptor then... lol, oh well... of coarse, by the same token, doubling the raptors capacity still keeps the track read times the same, making it effectively 5.8GB per track @ 0.4ms each, or, 11.6GB for 2 tracks @ 0.8ms total. which, if my math is right, puts both the F1 spinpoint and ADFD raptors at about the same performance overall, with the spinpoint being somewhat faster as a whole. (11.6GB+2.9GB (2.5 tracks) = 14.5GB 1.0ms 84MB/s partition compared to ~15GB 0.31ms 118MB/s partition)

 

[Futur]

well, take the F1 spinpoint that was just released which, if you partition the first 35GB of its 334GB platter, it will be a consistant 116-118MB/s for both reads and writes, since the heads wont need to move outside of that first 35GB barrier to do anything... unless you intentionally access data on another portion of the hdd at the same time, which would effectively reduce performance for both partitions.

I thought all the data was written to all platters from outside to the inside? Not filling one platter then the next etc.

 

[choirbass]

they do... what i was just meaning essentially was that if you double the workload on a hdd with 2 tasks instead of 1, you half its overall performance at that time. also that the r/w heads may need to move from one partition, all the way to another, which causes a relatively lengthy delay between data accessing. so instead of being .8ms for only 40GB, it may end up being as high as 20ms to access another 40GB track on the opposite end of the hdd depending on how far away inside the platter the other data is, and then it might have to go back to the first platter to access other data for another 20ms maybe, and then potentially back and forth. thats a worst case scenario, but thats what i was meaning though, just adding additional workloads that could significantly reduce the ideal performance that you posted about at first. ending up with access times that are up to 25 times worse than an ideal scenario of only <=0.8ms.

 

[SomeJoe7777]

reading the specs, it says it would take 20ms to read from one end of platter, all the way to the other end, assuming no stops inbetween. each track takes 0.8ms to read across. so 20ms/0.8ms=25 tracks @ 0.8ms each.
1000GB/25tracks=40GB per track @ 0.8ms each.

This calculation is not accurate, because the head seek time is non-linear with respect to the number of tracks that it passes over. There are overhead times involved in a seek that include the ramp-up and ramp-down times for the acceleration and deceleration of the head assembly, overshoot compensation times, and servo tracking times. These times themselves are variable, depending on the desired number of tracks the seek itself is supposed to take.

In addition, there are way more than 25 tracks on the platter - thousands, in fact.

Also, I must point out that in order to maintain the very low seek times that you can get by making a very small partition, the head assembly cannot leave that partition. If you partition the remainder of the drive and use it, then the head leaves the short-stroked area of the first partition, which kills its average seek time. Thus, if you want to maintain the low seek times, you have to leave the rest of the drive unpartitioned and unused.

Furthermore, let's keep in mind that short-stroking a drive like this only improves the seek time. It does nothing to improve the rotational latency time, thus establishing a lower bound on the resulting access time:

Seek time (head movement) +
Rotational latency time (waiting for a sector to rotate under the head)

=

Access to data time.

Average rotational latency for a 7200 RPM hard drive is fixed at 4.16 msec (1/7200 * 60/2). Thus, even if seek times drop to zero (possible, if you make a partition small enough such that it's all on one cylinder), the resulting average access to data time can be no less than the average rotational latency time of 4.16 msec. This is not even comparable to the access times for SSD's which are in the neighborhood of 0.1 msec. And this is where the Raptor and 15K SCSI drives still destroy you, with average rotational latency times of 3 msec and 2 msec, respectively.

Yes, you can improve your hard drive's performance by short-stroking, but only under the specific condition of not using the remaining space. And it doesn't improve the overall access to data time nearly as much as the benchmarks would have you believe.

 

[KyleSTL]

http://www.slashgear.com/gallery/data_files/1/4/6/samsung_f1.jpg
The first 4% (35GB) of that 1TB drive will have an average seek time of .31ms (A Raptor is 12 times slower than that) and a transer rate of 75MB/sec. Apart from a flash drive there is nothing that can touch that, especially in regards to seek time and trust me that is where the delay always is.

Really?!? You know human reaction time is like 300ms right? Do you really think the 11.69ms (12ms-0.31ms) is where the delay comes from? That is imperseivable. Now access time is a different story (engaging head, spinning platters, etc). That can be up to 10sec if you have certain energy-saving features enabled (turn off hard disks after __ min). I am HIGHLY skeptical about the perseivable performance with lower seek times.

 

[choirbass]

@ SomeJoe777: i didnt realize there were thousands... i was just taking the hdd info from the spec sheet on that page and basing it off of that. but, the rest makes sense, you explained it better than i did.

 

[Guest]

This calculation is not accurate, because the head seek time is non-linear with respect to the number of tracks that it passes over. There are overhead times involved in a seek that include the ramp-up and ramp-down times for the acceleration and deceleration of the head assembly, overshoot compensation times, and servo tracking times. These times themselves are variable, depending on the desired number of tracks the seek itself is supposed to take.

In addition, there are way more than 25 tracks on the platter - thousands, in fact.

Also, I must point out that in order to maintain the very low seek times that you can get by making a very small partition, the head assembly cannot leave that partition. If you partition the remainder of the drive and use it, then the head leaves the short-stroked area of the first partition, which kills its average seek time. Thus, if you want to maintain the low seek times, you have to leave the rest of the drive unpartitioned and unused.

Furthermore, let's keep in mind that short-stroking a drive like this only improves the seek time. It does nothing to improve the rotational latency time, thus establishing a lower bound on the resulting access time:

Seek time (head movement) +
Rotational latency time (waiting for a sector to rotate under the head)

=

Access to data time.

Average rotational latency for a 7200 RPM hard drive is fixed at 4.16 msec (1/7200 * 60/2). Thus, even if seek times drop to zero (possible, if you make a partition small enough such that it's all on one cylinder), the resulting average access to data time can be no less than the average rotational latency time of 4.16 msec. This is not even comparable to the access times for SSD's which are in the neighborhood of 0.1 msec. And this is where the Raptor and 15K SCSI drives still destroy you, with average rotational latency times of 3 msec and 2 msec, respectively.

Yes, you can improve your hard drive's performance by short-stroking, but only under the specific condition of not using the remaining space. And it doesn't improve the overall access to data time nearly as much as the benchmarks would have you believe.

VERY WELL SAID!

You are very well spoken and easy to understand explaining the complex interworkings of the HDD with respect to the average seek time and what not. Most of this thread I was hanging on trying to comprehend the numbers/expanations posted, and no I'm not stupid with math, BSME with a Math Minor here.

It appears you know a lot about HDDs where many people here know very little outside of benches. You should try to do a write up about this sort of deal and make it a sticky.

 

[Futur]

This calculation is not accurate, because the head seek time is non-linear with respect to the number of tracks that it passes over. There are overhead times involved in a seek that include the ramp-up and ramp-down times for the acceleration and deceleration of the head assembly, overshoot compensation times, and servo tracking times. These times themselves are variable, depending on the desired number of tracks the seek itself is supposed to take.

In addition, there are way more than 25 tracks on the platter - thousands, in fact.

Also, I must point out that in order to maintain the very low seek times that you can get by making a very small partition, the head assembly cannot leave that partition. If you partition the remainder of the drive and use it, then the head leaves the short-stroked area of the first partition, which kills its average seek time. Thus, if you want to maintain the low seek times, you have to leave the rest of the drive unpartitioned and unused.

Furthermore, let's keep in mind that short-stroking a drive like this only improves the seek time. It does nothing to improve the rotational latency time, thus establishing a lower bound on the resulting access time:

Seek time (head movement) +
Rotational latency time (waiting for a sector to rotate under the head)

=

Access to data time.

Average rotational latency for a 7200 RPM hard drive is fixed at 4.16 msec (1/7200 * 60/2). Thus, even if seek times drop to zero (possible, if you make a partition small enough such that it's all on one cylinder), the resulting average access to data time can be no less than the average rotational latency time of 4.16 msec. This is not even comparable to the access times for SSD's which are in the neighborhood of 0.1 msec. And this is where the Raptor and 15K SCSI drives still destroy you, with average rotational latency times of 3 msec and 2 msec, respectively.

Yes, you can improve your hard drive's performance by short-stroking, but only under the specific condition of not using the remaining space. And it doesn't improve the overall access to data time nearly as much as the benchmarks would have you believe.

Thankyou very much SomeJoe for enlightening me about this subject. It's really made sense of a lot of questions that I just couldn't find an answer to! Just one more query, if you did short stroke a 1TB drive to the ideal volume to reduce seek times, would you get almost maximum throughput for the drive consistently because the data is all stored at the edge of the platters? Or is this a myth?

 

[SomeJoe7777]

Just one more query, if you did short stroke a 1TB drive to the ideal volume to reduce seek times, would you get almost maximum throughput for the drive consistently because the data is all stored at the edge of the platters? Or is this a myth?

Just like a non-short-stroked drive, maximum throughput only occurs when sectors are being read precisely in sequential order. During a Windows startup, this isn't the case: many small files are being read, and those files are all over the partition. A single small file might be able to be read in 1/4 of a rotation of the platters (~ 2 msec), but if the next file isn't right behind it, then there's a seek time and a rotational latency involved, potentially involving up to a 10 msec wait, even on a short-stroked drive.

Since all tracks on a short-stroked drive are at the outer edge of the platters, any sequential reads can indeed be read at the drive's maximum throughput speed, but that doesn't help you if the reads aren't sequential.