This post is more than 5 years old

13 Posts

2

9670

# Confused about how IOPS is calculated in the "Information Storage and Management Storing..." book

This is my first introduction to IOPS calculation. I'm reading the oft recommend EMC book: "Information Storage and Management Storing...". The book explains IOPS is just a unit conversion of what it calls "Disk Service Time". I found googling, "Disk Service Time" is not as concrete a term in the industry as I thought after reading about it in the book- which is one problem. The other issue is the variables the book uses to calculate disk service time and how it just changes of one of them to something else- "data transfer rate" becomes "internal transfer rate".

When disk service time is first mentioned in the book it explains:

page 37:

"Disk service time is the time taken by a disk to complete an I/O request. Components

that contribute to the service time on a disk drive are **seek time,rotational latency,**

**and data transfer rate**"

It explains "data transfer rate":

"refers to the average amount of data per unit time that the drive can deliver to the HBA"

But then a few pages later, when IOPS is calculated, it says:

page 43:

"As discussed earlier in this chapter, the total disk service time (Ts) is

the sum of the **seek time** (T), **rotational latency** (L), and ** internal transfer time** (X):"

Um, no, as discussed earlier X was "data transfer rate". According to the book "** Internal** transfer rate" is the rate data moves from the platters to the disk's internal buffer. Also the "

**transfer rate" is not something vendors publish for their products so you would have no way of knowing this value and thereby would not be able to calculate disk service time or IOPS for the drive (according to the book).**

*internal*Then it gives you the following example of how to calculate the Disk Service time for HDD and uses the "**internal** transfer rate" again instead of the "data transfer rate":

"Consider an example with the following specifications provided for a disk:

- The average seek time is 5 ms in a random I/O environment; therefore, T = 5 ms.
- Disk rotation speed of 15,000 revolutions per minute or 250 revolutions per second — from which rotational latency (L) can be determined, which is one-half of the time taken for a full rotation or L = (0.5/250 rps expressed in ms).
- 40 MB/s
**internal data transfer rate**, from which the internal transfer time (X) is derived based on the block size of the I/O — for example, an I/O with a block size of 32 KB; therefore X =**32 KB/40 MB**.

Consequently, the time taken by the I/O controller to serve an I/O of block

size 32 KB is (TS) = 5 ms + (0.5/250) + 32 KB/40 MB = 7.8 ms.

Therefore, the maximum number of I/Os serviced per second or IOPS is

(1/TS) = 1/(7.8 × 10^-3) = 128 IOPS."

Now here is the other thing that confuses me: **X = 32 KB/40 MB**. Which the book says equals .8. What the heck is .8!? It just divided 32 by 40 without doing any unit conversion. .8 doesn't represent bytes, kilobytes, or megabytes so what is that value?

I know this is a long post, but I have not bee able to get any answers to these questions I have elsewhere.

carolineh1

15 Posts

1

November 7th, 2013 08:00

Hi red888,

One thing to clear up is that disk service time = seek time + rotational latency

+ data transfer. Aside from whether the term is "internal transfer" or "data transfer," you are adding atimetimeplus atimeplus atime(not a time plus a time plus arate.)In the example question you posted, .8 is the ratio of the data block size to the amount of data that can be transferred in 1 ms. You have .032 MB of data in the block (32/1024, with a little fudging). The disk is able to transfer 40 MB/s, or .040 MB/ms of data to the internal buffer (also called the cache).

Therefore, instead of taking a whole millisecond to transfer the .032 MB of data, it takes .032/.040 = .8 milliseconds (which is the ratio of block size to be transferred to the total data able to be transferred in 1 millisecond.) .8 ms is the data transfer

time, which we got using this formula: data block size/data transfer rate.So, putting it all together,

IOPS serviced by a disk = 1 / seek time + [.5/ (disk rpm /60)] + (data block size/data transfer rate)

In addition, for a performance-sensitive application, the best practice is to multiply the IOPS serviced by a disk by .7, to add some cushion to meet your performance requirements. In terms of what information the vendor provides, I'd keep asking around about what information to rely upon. Hope this helps!

~C

KEHutchinson

633 Posts

1

November 5th, 2013 13:00

I can tell you why 32 KB/40 MB equals 0.8.

Ts = 5 ms + (0.5/250 rps) + (32 KB/40 MB/s) = 7.8

From your question, I think you are forgetting to convert the MB/s into MB/ms.

red888

13 Posts

0

November 6th, 2013 06:00

Thanks for your reply I really appreciate it.

Forgive if I'm missing something, but wouldn't 32 kb =

.032mb (fudging 0.03125 of course)? I can confirm this with google.That would be .032 / .04 = 8 not .8

But my real concern is how IOPS is calculated. Is it impossible to calculate IOPS for a single drive yourself without knowing the internal data rate? Would you even want to? Should you always just rely on the vendor's stated IOPS?

What if a vendor provides the IOPS for a disk and doesn't provide the block size? Should I just assume it is 4kb (which is usually what manufacturers use for their IOPS ratings)? If I'm not sure of the block size for the stated IOPS then I can't convert to my application\File system's block size for an accurate measurement.

Anonymous

5 Practitioner

5 Practitioner

•

274.2K Posts

1

November 8th, 2013 05:00

Hi red888,

Answering your second question about the calculation of IOPS.

We've got 4 variables in 1 equation:

Ts = T + L

X+It means, that using this equation we could define only the one variable. Other variables should be predefined (that's the maths law). Hence, if a vendor provides the IOPs for the disk, but doesn't provide any information about seek time and rotational latency we cannot define the transfer rate. And so, we can't define the block size using this equation.

I suppose, that if you really need to know the block size you could ask your vendor to provide you with this information.