Today's meditation on the Blue Mysteries.
https://www.ardent-tool.com/docs/pdf/GG24-4002-0_IBM_PS_2_and_PS_ValuePoint_Subsystems_Dec92.pdf
Page 50 and 51 physical
Benchmarks
Many different utilities are available to perform benchmarks on disk subsystems. In doing benchmarks the final configuration and environment
should be emulated as closely as possible for testing.
Most of these utilities test the amount of time it takes to perform a
series of seeks on the drive as against measuring the time it takes to
read or write the data. The benchmarking utility will send repetitive
seek commands, moving the arm back and forth across the disk and
observing the time it takes to process each command or averaging the
time over a number of such commands.
In normal read/write operations, hard disks seek to a given cylinder
after which the arm does not move for some period of time while the read
or write takes place. As soon as the read or write has completed, the
drive is then ready to process the next command, which mayor may not
require a seek to a different cylinder.
This "rest period" that occurs after a seek has completed and the
reading or writing operation is taking place allows the arm drive
mechanism (voice coil) to cool down somewhat after being heated up by
the current necessary to perform the task.
The IBM SCSI implementation takes advantage of this natural cooling
action to boost the amount of current that can be used by the voice coil
during seeks. The more current used, the faster the seek. If the command
ends when the seek is completed, and the next command to be processed is
also a seek, then the natural cooling action to keep the voice coil at
an acceptable temperature is no longer available.
To prevent the drive from overheating from consecutive seek commands
while maintaining a maximum current for fast seeks, a delay of several milliseconds is added after the successful completion of the seek
operation. This delay simulates an average latency plus the read or
write time. This is why seek-based benchmarks are not suitable for
measuring the performance of SCSI disk drives as they simulate a
situation that doesn't occur in the normal operation of the disk and, as
a result, show performance figures that do not represent the" real life" -performance of the drive.
Many seek-based benchmarks would probably measure a non-SCSI device as
being quicker than a SCSI device, even if it were actually slower. Most non-SCSI devices will run at the speed of the processor for all I/O
operations. This would tie down the processor for the period of I/O, but
in turn would make the non-SCSI device perform well in the benchmark.
SCSI devices are normally bus masters, and often detach from the main
processor and perform I/O transfers at the speed of the SCSI processor,
which is much slower than the main processor.
When actual applications are loaded into the system, especially in a multitasking environment, the SCSI devices normally outperform non-SCSI devices. This is because the system processor has to wait for I/O
processes to complete with non-SCSI devices. With SCSI, however, the bus-mastering capability allows the SCSI controller to release itself
from the main processor (allowing it to perform other tasks) while
allowing the SCSI controller to perform disk operations at the
same time.
Benchmark Summary: Overall, any benchmarks must be carefully analyzed
and the other benefits of SCSI taken into consideration before a
decision is made on which system will best suit the user. Different
tests test different parameters, and the only valid and relevant data
would be obtained when the actual application is tested on the final configuration. A pilot test period with real applications and real data
is strongly recommended in any benchmark test.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)