You surely have already seen those figures, a 15K disk does +/- 210 IOPS whilst SATA disk can barely achieve 30-40 IOPS.
How do they do to determine disks IOPS?
It is far from obvious and you must refer to the technical details provided by the disk manufacturer and use a simple formula given below. Also this is the theory, no file system, no data, no OS, this is raw disk power right off the pipe. Now let’s have a look at the formula:
1/(average latency in ms + average seek time for read or write in ms)
This is the specifications of a Seagate Cheetah 300GB 15K disk and actually have a look at the latency and seek times, that’s what we need for the formula.
So for this particular disk, theoretically the maximum we can expect is 1/(.0022)=454IOPS
And for the minimum, that I would call the best of the worst case, we can expect 1/(.006)=166IOPS
That gives us an average of 310IOPS! Not bad for the latest of Seagate’s high end disks family.
Now that you have the formula, go and check your own disk max/min/average IOPS and post it here 😉
Also read my other post on IOPS where I give the formula to calcuate the IOPS you can expect of a virtual environment.
DeinosCloud 
Pingback: 10 Biggies to Help Managers and Admins Avoid Virtualization Pit-Falls « DeinosCloud
Hi,
A valiant attempt to determine IOPs, but wrong … talking theoretical maximum is pointless. In theory one could get into an IO loop reading onlydata from a single track thus eliminating track seek times and the measured performance gets event better.
In reality one must take the Average Seek time to get a real feel for the maximum performnce of a disk in th ereal world.
Workloads are being condensed onto a smaller footprint and thus there is more contention and thus all IO tends to be random so the average response is the measure.
So for real world plannng using the 166 IOPs when sizing solutions … 310 IOPs – thats a pipe dream …
Tony
You are absolutely right Tony… This is theoretically the maximum speed you could get, as stated, raw power. In real world, this is another story and a subject for another article, stay tunned 😉
How are you getting the 0.0022 number when calculating the first IOPS of 454? I add average latency and average seek read time, and get a 5.5.
Hi Ahmed. Average Latency (2ms or .002s) + Seek Time Track-to-Track Read (0.2ms or .0002s) = 2.2ms or .0022s
IOPS are per second (s), and often disk time and latency specifications are in miliseconds (ms) which is 1/1,000 of a second (s).
I hope it clarifies the formula…
Cheers,
Didier
N.B. Look at this link http://unit-converter.org/UnitConverter/convert?uc_class=12&uc_value=2.2&uc_sigdigits=5&uc_unit=415&uc_cat=all&commit=Convert
Pingback: QNAP TS-639 Pro Turbo NAS Part 2 « DeinosCloud
Pingback: Top Posts In 2009 « DeinosCloud
That is a simple and good explanation.
Fundamentals are very much needed in the market place.
All vendors/pre-sales/consultants need a lot of basics to be understood. Appreciate your effort.
I wanted to post here a link to an awesome article from Scott Lowe about the very same subject… Worth a read and bookmark for future reference!
http://blogs.techrepublic.com.com/datacenter/?p=2182
Pingback: Tons of Formulas For My Virtual Infrastructure « DeinosCloud
Pingback: A Year Blogging In Summary And Season’s Greetings « DeinosCloud
Pingback: A Year Of Blogging In Summary And Season’s Greetings | DeinosCloud
What would the IOIPs be for a journaling application (as in a DB journal) where one has a decidcated disk and one is writing to the end of the file that has been preallocated to be contigious.
There is a better, more accurate and less flattering way to establish IOPS you can expect from a disk. The IOPS are fundamentaly dictated by spindle speed.
If we need to read a sector, we have to align the head to the required cylinder, and wait for the sector we require to go under the head. These two operations are happening simultaneously, so we can actually simplify this to just the time it takes for the sector to come around.
That means that on a 15,000 rpm disk we can only expect at most 250 random access IOPS. This also directly translates to random seek time we can expect from a disk: 250 IOPS means 1s/250=4ms. On high-rpm disks, head movement needs to be very quick to actually align fast enough to not have to wait for the sector to come around again, which is why 15,000rpm disks use very small diameter platters. Another thing to bear in mind is that these are theoretical limits – in reality the average performance achieved will be worse. Depending on how you optimized and aligned your RAID array and file system, it could be a LOT worse. (See here for a longer article on optimizing RAID and file systems: http://www.altechnative.net/2010/12/31/disk-and-file-system-optimisation/ )
If you stick with these fundamental estimates based purely on the mechanical constraints, you won’t go far wrong. All the other figures published by hardware vendors are just smoke and mirrors misdirections designed to bamboozle you into thinking their product is somehow better than their competitors’.
Gordan thx for you comment.
This formula is indeed theoretical and using fundamental laws governing disk performance.
At the end of the day you indeed need to take into account multiple other factors and variables. Some of them, that I would call the logical components, are: interface, OS, device drivers, LVM, RAID type, file system, apps, etc.
And indeed 1s/250=4ms, that is a full rotation measurement. Average would be half of that, that’s 2ms, thus expected 500 random IOPS.
Thx,
It doesn’t actually work like that. 250 IOPS / 4ms is around the theoretical maximum. The other factors and variables are going to inevitable make it worse, not better.
Also, the average wouldn’t be half of the 4ms because the minimum is not actually bound at 0ms. If you are reading from the same cylinder then unless it is the same sequential operation you’ll have to wait for the sector to come around. If you are not reading from the same cylinder you are going to have to perform at minimum a track-to-track seek to an adjecent track or switch to a different head/platter, both of which typically take _at least_ between 0.2 and 0.8ms. Full stroke seek time will be a lot greater, but the rotational latency is always dominant (which is why short-stroking disks to half capacity only yields minimal improvements).
In any realistic multi-user/multi-process workload you shouldn’t expect to see more than about 200 real IOPS from a 15K rpm disk. Fire up something like “iostat -d 5” on a heavily disk I/O bound system and you’ll see that your IOPS will hover just below the IOPS you would expect just from the rotational latency (unless your load is very sequential and not very parallel).
Amen to that!
Thx for your comment Gordan.