These are the Frequently Asked Questions about Iometer.  This
information is provided by Intel as a convenience to Intel's general
customer base.  Intel assumes no responsibility for any errors which may
appear in the document nor does it make a commitment to update the
information contained herein.

For more information, see the Iometer User's Guide provided in the
Iometer ZIP file (available for download at
<http://developer.intel.com/design/servers/devtools/iometer/>).  If you
still have questions after reading the documentation, send them to
"iometer@intel.com" and we'll get back to you as soon as we can.  If you
are reporting a bug, please include a setup.txt and results.txt file
demonstrating the problem.


========
PROBLEMS
========

Q: Why is my throughput (MBps) so low and CPU utilization so high?
A: The most likely cause is a small transfer request size in the access
   specification.  For the most throughput with the least CPU
   utilization you should use large (256KB or larger) requests.

Q: Iometer hangs, crashes, and/or gives unreasonable results.  Is this 
   a bug?
A: The most common cause of this problem is a large total value for
   # Outstanding I/Os.  This is a driver/OS problem, not an Iometer
   problem.  If you use a very large total size of outstanding I/O
   buffers (# Outstanding I/Os * number of disks per worker * number of
   workers * size of each I/O), especially with large sequential I/Os,
   the system can run out of virtual memory, resulting in thrashing,
   hanging, or crashing.  The exact definition of "very large" depends
   on the disk driver and the amount of memory available on your system,
   but you are likely to have problems if the total size of outstanding
   I/O buffers is greater than the amount of physical RAM in your
   system.

Q: Sometimes all the I/O-related results for a test are zero, but the
   CPU-related results are as expected.  Is this a bug?
A: This can be caused by a test run time that is too short.  Check the
   "Read I/Os" and "Write I/Os" columns in the results file.  These
   values indicate the number of read and write I/O operations that
   completed during the test.  If these values are zero, it indicates
   that no I/Os completed before the end of the test and there will be
   no disk-related results.  Try increasing the run time until these
   values are large enough to give statistically significant results (at
   least 2000).

Q: The I/O-related results display as -0.0 or unreasonable huge values.
   Is this a bug?
A: This problem has been reported only on very old machines (90MHz
   Pentium processors running Windows NT* with no service packs).  It
   can be avoided by using a newer computer and/or OS.  The source of
   the problem is not yet known.  Installing the latest NT service pack
   on a machine with the problem does not appear to help.  If you have
   this problem and are willing to work with us on a solution, please
   send mail to "iometer@intel.com".

Q: The documentation references a bug in Diskperf that double counts
   several of the disk counters.  Is this an open issue in all versions
   of NT?  Are there specific circumstances where it shows up?
A: It seems to be present in all versions of NT 4 and is *not* fixed by
   SP 3.  We don't know if it's still present in NT 5.  It always shows
   up for the counters listed in the documentation if you are accessing
   a physical disk (PHYSICALDRIVE:n).  It does not seem to affect
   logical disks or any other counters.  We are not aware of any
   Microsoft documentation discussing the problem.  The problem does
   *not* affect Iometer; Iometer gathers these statistics directly
   rather than from Diskperf.

Q: When I start the Import/Graph Wizard, the initial value shown in the
   "Specify the Iometer results file" box is "48", and no matter what I
   do I always get a "File Not Found" error.
A: The "48" is an error code.  It indicates that a DLL required by the
   wizard is missing.  You need to run the MS Office 97 Setup program,
   select Add/Remove Components, go into the "Data Access" component,
   and install "Data Access Objects for Visual Basic".  If the component
   is installed already, or if installing it doesn't fix the problem,
   send mail to "iometer@intel.com" and ask for a copy of the DAO setup
   program (3.2MB ZIP file).


================
ACCESSING DRIVES
================

Q: Can you run a test without destroying the existing files on a disk?
A: If a disk has any files on it, it will only be visible if it is
   mounted as a logical disk (A: through Z:).  Logical disks are
   accessed through a file called "iobw.tst" at the root of the disk.
   If this file does not exist, the test begins by creating the file and
   expanding it until the disk is full; this stage is shown as
   "Preparing Drives" in the status bar.  No existing files are
   destroyed, but the disk will be 100% full.  Alternatively, you can
   create the iobw.tst file at any desired size before running Iometer.
   (Note that Iometer must have both read and write access to the
   iobw.tst file.)  If you use Iometer on a physical disk, PHYSICALDISK:0
   through PHYSICALDISK:n, it accesses the physical disk device.
   Writing to the physical disk device is destructive, but PHYSICALDISKs
   are not visible unless they contain nothing but free space, so no
   data is ever destroyed.

Q: The "Preparing Drives" phase takes a long time.  What is happening
   during this time?
A: When writing to a logical drive that has not been prepared (that is,
   one that is shown as a yellow disk icon with a red slash), the
   preparation consists of creating a file called "iobw.tst" at the root
   of the drive and writing to it until the drive is full.  Drives are
   prepared one at a time, to prevent having two workers try to prepare
   the same drive at the same time.  This means that if you have many
   large drives to prepare, it may take a very long time.  The
   preparation step is skipped if the iobw.tst file exists (even if it
   does not fill the disk).  You can avoid the preparation time by using
   physical rather than logical drives, or you can create the iobw.tst
   file yourself before running the test.

Q: How is I/O distributed when I choose multiple workers on the same disk?
   Does each worker get a portion of the disk, or is each worker interleaved 
   at some block or extent level, or what?
A: If multiple workers are assigned to the same disk, each of them uses
   the entire disk (all at the same time).  In general, you should
   assign only one worker to each disk (you can do this easily by
   assigning all the disks to the manager; the manager will distribute
   the disks to its workers in a round-robin fashion).  To simulate the
   effect of multiple threads writing to a single disk, raise the "#
   Outstanding I/Os".

Q: How do I prevent a drive from appearing in the list of disks to be
   tested?
A: You can prevent a mounted logical drive from appearing in the list by
   creating a read-only file called "iobw.tst" at the root of the drive.
   (It can be of size zero bytes.)  If Iometer finds such a file, it
   assumes the drive is read-only and does not list it.

Q: Is there any way to force Iometer to access the disk cache only?
A: Not really.  You can set the Maximum Disk Size to a value equal to or
   smaller than a cache segment, in sectors, which will force Iometer to
   access the same sectors over and over.  In most cases this will
   result in cache performance, but some drives will access the physical
   disk anyway.  For example, the drive firmware may assume that
   repeated reads from the same sector want data from the physical disk
   (because if you wanted cached data, the OS would have cached it for
   you).  Also, repeated writes to the same sector may always go to the
   disk even if the data is the same.  Contact your drive vendor for
   details.


==================
TEST CONFIGURATION
==================

Q: How should I set the Iometer parameters to get the best results?
A: For the best throughput (highest MBps), use 64K sequential reads with
   "# Outstanding I/Os" set to 1 or 2.  (You may see slightly better
   throughput with transfer sizes larger than 64K, if the driver
   supports it.)  For the best I/O rate (IOps), use 512-byte sequential
   reads with "# Outstanding I/Os" set to 1 or 2.  In general, though,
   you should set Iometer's parameters to match the workload of your
   typical application or benchmark, as described in the documentation
   under "Using Iometer to Simulate a Real Workload." Then you can use
   Iometer to measure several different I/O cards, disks, drivers, or
   configurations under the same workload, so you can select the best
   one.

Q: Why are the assignments of targets and access specifications to
   workers not saved when saving the test configuration?
A: This feature has not yet been implemented.  It has been requested by
   several users and may be provided in a future release of Iometer.

Q: How do I use Iometer for network testing?
A: Press the "Start Network Worker" button to create a network server on
   the selected manager.  Click on the server to see the list of all
   machines that Dynamo is running on and the list of network interfaces
   on each machine.  Click on an interface to select it.  A network
   client will be automatically created on the corresponding manager to
   handle the other end of the connection.

Q: How does the # Outstanding I/Os affect the workload? 
A: The "# Outstanding I/Os" is the number of simultaneous I/O operations
   per disk that is maintained by each worker.  For example, if the "#
   Outstanding I/Os" is 5, the worker would start 5 I/O operations to
   each of its disks, then wait until one of them completed before
   starting another one.  This can be used to simulate the work of
   multiple simultaneous processes or threads.

Q: How do the "Burst Length" and "# Outstanding I/Os" parameters
   interact?
A: The "# Outstanding I/Os" parameter controls the maximum number of I/O
   operations that are in progress at one time.  The "Burst Length"
   parameter controls how many I/O operations are initiated without
   pausing.  After each burst, the "Transfer Delay" parameter controls
   how long Iometer pauses before beginning the next burst.  If the
   burst length is greater than the number of outstanding I/Os, the
   worker will initiate the specified number of outstanding I/Os and
   then wait until an I/O completes before queuing another I/O -- but it
   will not add any additional sleep time between I/Os, it will fire off
   I/Os as fast as it is able to.  When the total number of I/Os
   specified by "Burst Length" has been initiated, the worker will then
   sleep for the time specified by "Transfer Delay" before starting any
   other I/Os.

Q: What is the difference between "# Outstanding I/Os", "Transactions
   per Connection", and "Burstiness"?
A: "# Outstanding I/Os" (Disk Targets tab) controls the maximum number
   of I/O operations per disk that are in progress at one time.
   "Transactions per Connection" (Disk Targets and Network Targets tabs)
   controls the number of transactions (request + reply) issued to a
   given disk or network target before the target is closed and
   re-opened.  "Burstiness" (Edit Access Specification dialog) controls
   the number of transactions issued without pausing; if the Transfer
   Delay is zero, the Burst Length value is not significant.  For
   example, suppose you have a disk worker with one disk and the #
   Outstanding I/Os is 10, the Transactions per Connection is 20, the
   Burst Length is 40, and the Transfer Delay is 50.  In this case, the
   worker begins by firing off 10 I/Os to the disk (# Outstanding I/Os).
   As each of the initial 10 I/Os completes, it is immediately replaced
   by a new one until the total number of I/Os reaches 20 (Transactions
   per Connection).  At this point the disk is closed (which does not
   complete until all outstanding I/Os complete) and then immediately
   re-opened.  A new batch of 10 I/Os is initiated, and each is replaced
   by a new one as it completes until the total number of I/Os reaches
   40 (a multiple of Transactions per Connection), when the disk is
   again closed.  Since 40 is also the Burst Length, the worker sleeps
   for 50 ms (Transfer Delay), then opens the disk and begins again.

Q: What is the relationship of the number of workers to the 
   "# Outstanding I/Os"?  Is 10 workers with 1 outstanding I/O each the
   same as 1 worker with 10 outstanding I/Os?
A: They are similar but not identical.  Each worker is a thread, and
   each thread imposes some OS overhead -- especially if the number of
   threads is greater than the number of processors.  All other things
   being equal, you should expect to see slightly lower performance with
   10 workers than with 1 worker.  In general, you should have one
   worker per processor (this is the default) and change the 
   "# Outstanding I/Os" to produce the workload you desire.

Q: What do the "Starting Disk Sector" and "Maximum Disk Size" controls do?
   How can I determine the correct values for these controls on a
   logical disk which has files on it already?
A: The "Starting Disk Sector" is the lowest-numbered sector used in the
   test.  It is measured from the beginning of the disk for a physical
   disk, or from the beginning of the iobw.tst file for a logical disk.
   The "Maximum Disk Size" is the number of sectors used in the test.
   If it is greater than the size fo the disk or iobw.tst file, it is
   ignored.  For example, if you set the "Starting Disk Sector" to 500
   and the "Maximum Disk Size" to 200, the test would access only
   sectors 500-700 of the disk or iobw.tst file (or to the end of the
   disk or file, if it's smaller than 700 sectors).

Q: I would like to automate a series of tests that varies parameters not
   shown in the Test Setup tab, such as the I/O size and read/write
   ratio.  How can I do this?
A: Create a series of access specifications that performs the desired
   series of tests and assign all of them to the worker(s).  Multiple
   access specifications will be executed in sequence.  You may find
   that it is easier to create a complex series of access specifications
   by editing the "setup.txt" file with a text editor.


=======
RESULTS
=======

Q: Is there some way to save the results to a database or spreadsheet
   instead of a text file?  Is there a way to automatically produce
   graphs of the results?
A: The Import/Graph Wizard (wizard.mdb) will import Iometer results into
   a database and create graphs of data from a database (requires
   Microsoft* Access* 97 and Microsoft Excel* 97).  

Q: What do all the numbers in the results file mean?
A: Most of the results in the results file are the same as those
   displayed in the Results Display tab, which are described under
   "Selecting a Statistic for Display" in the "Results Display Tab --
   Reference" section of the documentation.  The ones that are not
   documented are the raw totals (which are provided in processor ticks
   and can be ignored unless you are doing low-level I/O analysis) and
   basic configuration info such as the number of workers per manager.


=========
INTERNALS
=========

Q: At what level does Iometer call into the NT file system?  Is the I/O
   buffered?  Are the I/Os synchronous or asynchronous?
A: Iometer accesses logical disks (yellow disk icons) through a file in
   the disk's file system (e.g.  NTFS or FAT); it accesses physical
   disks (blue disk icons) through the RAW file system.  In either case,
   it uses the FILE_FLAG_NO_BUFFERING flag on the CreateFile() call,
   which instructs Windows to open the file with no intermediate
   buffering or caching.  There may, however, be buffering in the disk
   device or the adapter.  Once the disk has been opened, Dynamo uses
   the standard ReadFile() and WriteFile() calls to access it.  The I/Os
   are performed asynchronously, using I/O completion ports to determine
   when each asynchronous I/O has completed.

Q: What errors are counted by the "Error Count"?  Does Iometer check
   that the data has been read/written properly?
A: Only errors that cause the ReadFile() or WriteFile() call to return
   an error code are counted.  Iometer does not perform any data
   verification at this time.  Data verification is extremely difficult
   when multiple processes are simultaneously writing to the same disk.

Q: What is the synthesized data that is used in the I/Os?
A: The data buffer is not initialized after being allocated, so the data
   written is unpredictable.  The data read is whatever happened to be
   on the disk at the time.

Q: What is the resolution of the clock Iometer uses to time I/O latency?
A: We use an assembly-level call that reads an always-increasing counter
   stored within the processor.  The counter is updated every processor
   clock cycle, so the resolution is the inverse of the processor's
   speed.  In a multi-processor environment, the accuracy of the
   response time depends on any differences between the counters in
   different processors.  This is in the nano-second range.

Q: How does Iometer gather CPU utilization information?
A: The CPU utilization statistics are obtained from the Registry, the
   same as Perfmon.  We do not currently use the processor's performance
   counters.

Q: How does Iometer generate its random numbers?
A: The random values are generated by a thread-safe 64-bit random number
   generator which we wrote.  It is similar to the standard NT rand()
   call except for the number of bits.  Each thread uses the number of
   clock ticks since boot as its random number seed.

Q: Iometer never seems to issue SCSI bus commands over 64K.  Is this a
   bug?
A: Iometer issues I/O requests of the size you specify (up to 1024MB,
   depending on available memory), but those requests are converted into
   SCSI commands by the OS and driver.  The IO Manager or driver, most
   likely the driver, is choosing to issue a series of 64K requests
   rather than a single request for the full size of the I/O.  Some
   drivers have registry entries (e.g.  MaximumSGList) that allow them
   to send data greater than 64K, if the hardware can handle it.
   Consult your driver documentation for details.

Q: Is there a more detailed explanation of the test procedure?
A: The User's Guide is the only document available at this time.  If you
   have any specific questions, send them to "iometer@intel.com" and
   we'll answer them as best we can.


=============
MISCELLANEOUS
=============

Q: What operating systems does Iometer run on?
A: Currently Iometer runs only on Windows NT 4.0 and above.  A port to
   Solaris* (Intel Architecture only) is currently in progress; if you
   would like to try it when it is available, please send a request to
   "iometer@intel.com".  If you are particularly interested in any other
   operating systems, please let us know at "iometer@intel.com".

Q: Does Iometer work under Windows NT 5.0?
A: Iometer version 1998.08.24 has been run under NT 5.0 Beta 2 and
   seems to work, but has not yet been extensively tested.

Q: Does Iometer work under Windows 95* or Windows 98*?
A: No.  It uses performance data that is not present in the Registry
   under Windows 95/98.

Q: Does Iometer work under Windows NT on the DEC* Alpha* microprocessor?
A: No.  No such port is planned.

Q: What is the difference between Iometer and IPEAK?
A: Iometer is an I/O workload generator and performance analysis tool
   that provides overall, system-level performance and scalability
   analysis for disk and network I/O.  For more information on Iometer,
   see <http://developer.intel.com/design/servers/devtools/iometer/> or
   send mail to "iometer@intel.com".  IPEAK is a family of performance
   analysis tools, which currently includes the Graphics ToolKit, the
   Power ToolKit, and the Storage ToolKit.  Each of these toolkits
   provides detailed, subsystem-level performance analysis for a
   specific subsystem.  For more information on IPEAK, see
   <http://developer.intel.com/design/ipeak/> or send mail to
   "ipeak@intel.com".

Q: Can Iometer be controlled from the command line, for batch operation?
A: The only command-line control in the current release is an optional
   <file>.icf argument to specify access specificactions and test setup
   parameters.  Full command-line control has been requested by several
   users and may be provided in a future release of Iometer.

Q: Are there any predefined test patterns available?
A: All available access specifications are included in the Wrkloads.icf
   file.  If you develop any access specifications that you would like
   to share with other Iometer users, please send them to us at
   "iometer@intel.com".

Q: Is the version of Iometer on the web page the full version?
A: Yes, it is the full version.  There is no "demo" or "limited"
   version.

* Third-party brands and names are the property of their respective owners.

-- END OF FILE --
