“If only we could still get 36GB disks for speed”
February 18th, 2011 | 
Author: Yesterday I remembered a rather funny discussion I once had. Someone stated “if only we could still get 36GB 15K disks, we could speed things up by using a lot of spindles”.
Kind of a funny thing if you think about it. At the time I figured that 36GB disks would force you to use more drives in order to reach a proper capacity. And since a lot of people still tend to scale to capacity only, your problems increase with the size of disks. Let’s say your environment requires 6TB, you could use 4 2TB drives in RAID5 – But don’t expect 100 VMs running properly from that 😉
The funny thing (and the reason for this post) is that most people seem to miss out on the following…
The latest thing: vTesting!
Yes I admit it, now that I’m an EMC vSpecialist I do not have very much time left for all these deepdive measurements. So I’m forced to introduce a new type of testing. I’ll call it a vTest. Actually Einstein is the father of this type of testing, simply because he did not have spaceships that could do near-lightspeed. Me, I simply lack time. Hm that is a kind of deep statement in this light right 🙂
With no further delay I’ll just drop the statement for this vTest, and we’ll boldly go where no geek has gone before:
So how many of you think the above is pure nonsense? Don’t be shy, let’s see those fingers!
Now for the actual vTest: In this test I play the devil’s advocate and use a 2TB 7200rpm SATA drive, and a 36GB 15K FC disk. Both disks get 36GB of data carved out. Now we run a vTest performing heavy random access on both 36GB chunks.
See where I’m going? If not, here is a hint: Throughput part 1: The Basics. In random access patterns, the biggest latency in physical disks comes from the average seek time of the head to the correct cylinder on disk. And the trick is in the “average” part.
The average seek time is the average time required for a head to seek to any given cylinder on the disk. But this seek time heavily depends on where the head was coming from. Normally the average seek time is measured when the head needs to travel half of the platter’s surface. But in our test that is far from reality for our 2TB SATA drive!
As the 36GB 15K FC drive has to move its head all over the platter, the 2TB SATA disk only moves (36GB/20000GB)*100 = 1,8% of its total stroke distance. In fact even that is a lie: The outside of the platter carries way more data than the inside, so assuming the 36GB is carved out at the edge (what most arrays do), this number is even lower, probably below 1% !
This means the average seek time of this disk is no longer around 8-9ms, but drops to around 1ms (no, not 1% of 9ms! This value will be very near the track-to-track seektime which for SATA usually is around 1ms). Even the addition of the extra rotational latency of the SATA disk (because it spins at 7200rpm instead of 15000rpm) does not help: The total average seek time is still way lower than the total average seek time of the poor 36GB 15K disk…
Yes you could discuss on caching efficiency; the way the disks differ in sorting the order in which they fetch random blocks, but still:
(At least it should get you thinking!)
Posted in 
Tags: 
LinkedIn
Twitter
[…] This post was mentioned on Twitter by Erik Zandboer, Erik Zandboer. Erik Zandboer said: New blogpost: “If only we could still get 36GB disks for speed” … introducing vTesting 🙂 http://bit.ly/g1ahpi […]
The 1ms average seek time on the 1% of the SATA drive assumes you will NOT be tempted to use the other 99% of the SATA drive… Who can resist that?
If I split my SATA drives in half and use the inner half only for backups (and thus stay away from it during peak), can I get performance close-enough to FC disks that I’ll be happy with them. Personally, in that case I think the SATA drives will still be “slower but close-enough”, but I really don’t have any numbers.
Or a better question is: what percentage of the drive would need to be idle on the SATA drives for them to perform as good as the FC drives?
Hi Kurt,
The idea would be that a 2TB SATA drive does not cost much more than a 15K 36GB would today. So yes, you’d have to leave a very big blank space on the drive, or use it just for archiving. A lot of people do this without even realising it. As soon as you create a LUN for “bootdrives”, it means all bootdrives will be close together on the spindle (assuming you have a conventional array). Testing the break-even point would be a real pain though 🙂
Funny thing is that we something alike on SSD drives: You buy 60GB, while IRL it is somewhere between 70 and 80GB I think. Just as a safety net in this case, but still… So we could possibly sell very fast 36GB drives which are secretly shortstroked 2TB SATA drives 😉
> But this seek time heavily depends on where the head was coming from.
This statement is not quite correct. Drives can move the head very fast. The majority of the seek time is spent waiting for the target data to slowly rotate around and come under the head.
This is where NCQ really makes a difference. It can optimize not only for track-to-track seeking, but with many concurrent reads, can optimize read-order based on what part of the disk is approaching the reading area next.
Hi Dan,
Actually the statement on rotational latency IS true. If you calculate, even a 5400rpm disk will do a full rotation in 1/5400 = 0,185 [ms]. Most 5400rpm drives have an average seektime around 9[ms]. As you can see, rotational latency is only a VERY small part of this.
NCQ especially helps in logically “sorting” the cylinders to access, not so much the “spot on the circle” (although I think NCQ tries both).
Yes the heads move really fast. But think of it: The head races from inside to outside. It then has to break, slow down, and do a very precise calibration so that is hoovers exactly over a track to read. That takes time.
Also remember that what is stated in the specs of a harddisk is the AVERAGE seektime. That is when the head has to move across half the platter (hence the word average).
Check out the “track to track” seektime which is sometimes specified as well. This is VERY small compared to the average seektime, which also shows the rotational latency is very small.
Hi Erik,
Interesting thought, would like to test to see if it’s true..
One comment though. The speed of a 5400 rpm disk is 5400 rotations per minute, not per second. Which brings a full rotate to 11,1 ms (not 0,185). A 15K rpm will do the full rotation in 4 ms.
Rotational speed DOES count. I would bet a beer or 2 that the 36G 15K FC drive is still faster than the 2TB SATA, given all else similar (so keep disk cache differences etc out of the equation).
Besides, the SCSI (and FC) protocol supports disconnect so the disk can accept another I/O request while the first one is being processed. A SATA disk cannot, so it has to wait during the head movement and then (partial) rotation and can do no other stuff in the meantime (such as sending data from disk to adapter while searching for the next disk offset). Which is a huge difference in mixed workloads (i.e. databases) but doesn’t show in single-threaded test (the infamous copy/dd tests, or iorate/iometer tests with one worker).
Regards,
Bart