Reviews Leaderboard Database Reference Search StorageReview Discussion Reliability Survey Search About StorageReview.com Contents

Second Anniversary!
3/13/2000 - SR`s IOMeter Tests
3/14/2000 - The New Database


Operating Systems and Benchmarks - Part 4
  March 13, 2000 Author: Eugene Ra  

Introducing Intel's IOMeter

Our previous synthetic benchmark of choice was ThreadMark 2.0. Very early on, however, we noticed an unhealthy correlation between high ThreadMark scores and high STRs as reported by WinBench. Nowhere was this more evident than on ThreadMark's marked increase in reported performance of RAID 0 configurations (in contrast to the very slight gains exhibited by WinBench) and on scores with drives such as Quantum's Bigfoot series, a dog-slow line that nonetheless sported respectable STRs. We thought about phasing out the measure, yet every time we dropped such hints, we received mail from those who begged us to keep the test, claiming that it correlated to their uses. The last straw, however, was the amusement expressed by representatives from Adaptec themselves, creator of the program, when we told them we use ThreadMark as a benchmark. Their advice was an idea that we'd been toying with for some time: Use Intel's IOMeter.

IOMeter isn't the user-friendliest program around, but it's definitely the most flexible. Unlike WinBench 99, which uses access patterns created by real applications, IOMeter's patterns are entirely synthetic. Such synthetic nature, however, yields incredible flexibility.

The program's scope extends beyond that of simple, single-disk testing as we perform here at StorageReview.com. It can test multiple disk setups, multiple CPU setups, and multiple-machine setups across a network. In our brief explanation here, we're going to restrict ourselves to a single-machine, single drive setup.

IOMeter can spawn multiple workers; Intel recommends one worker per CPU. Each worker, in term, can tax target (s) consisting of either an unpartitioned "physical disk" or partition(s) within a disk. Each worker must also be assigned a specific "access pattern," a series of parameters that guide the worker's access of a given target.


Access Pattern Variables include:

Transfer Request Size- the smallest block unit that the worker will deal with. Sequential transfers would result in a doubling, tripling, quadrupling, and so on of this base size.

Percent Random/Sequential Distribution- the percentage of requests that will be random in nature. If a request isn't random, then, of course, it's sequential.

Percent Read/Write Distribution- the percentage of requests that will be reads as opposed to writes.

These three major categories can then be shoehorned into a given percentage (Percentage of Access Specification), and combined with other balances to form an aggregate access pattern representative of nearly any use.

The final setting of note is the # of Outstanding I/Os, a setting that can be assigned to each worker to vary the load the worker places on a given target with its access patterns.

Confused yet? It's a bit difficult to explain on paper, but the actual program isn't quite so complex. What's clear, however, is that the program's tremendous flexibility raises this question: What represents a fair access pattern and load?

 StorageReview.com's IOMeter Tests


HOME | ARTICLES | LEADERBOARD | PERFORMANCE DATABASE | REFERENCE GUIDE
COMMUNITY | RELIABILITY SURVEY | SUPPORT SR! | ABOUT SR |

Copyright © 1998-2005 StorageReview.com, Inc. All rights reserved.
Write: Webmaster