VESA Local Bus IDE vs ISA IDE - some thoughts on benchmarks
Vadim V. Vlasov
I'd like to shed some light (or set more questions?) on the problem of choice
between VL-bus IDE and ISA IDE.
In article <1993Apr29....@cucs5.cs.cuhk.hk> wk...@cs.cuhk.hk
(Peter Wai Kwok Lie) wrote:
> I'm seeking benchmark results of using the same hdd (say, Quantum
>LPS240 IDE) in the same VL-Bus Intel 486 machine (without any software
>cache), but difference in:
>
>1. ISA IDE card
>2. VL-Bus IDE card with hardware cache *disabled*
>
> Suggested test platform: VL-Bus i486DX-33 256k cache, DOS 6 without
>DoubleSpace and without SmartDrv. Benchmark software: CoreTest 2.92
>(available in Simtel mirrors: (msdos)/dskutl/core292.zip or
> garbo: /pc/diskutil/core292.zip )
And in <C69y5...@news.iastate.edu> sco...@iastate.edu (Scott Bilas)
published the results:
>You're in luck! I happen to own a local bus machine. [...]
>It's a 486DX-33 with a 256K cache and DOS 6. [...]
> The drive tested was a Maxtor 7120A 130M hard drive,
>15ms access, and a DAMN NICE drive I might add. I happen to own two!
>Anyways, a friend of mine also had a Maxtor, same model, only on an old
>Packard Bell 386SX-16 with your standard 16-bit IDE interface. I ran the 1992
>Coretest on both machines in the above software configuration, and the access
>times differed by around .1 ms for average seek. And the transfer rate, which
>came to something like 1260K/sec for my machine, was 1210K/sec for the SX. A
>difference of 50K/sec?! That's right. I was amazed as well, since I spent an
>extra 50 bucks to get local bus IDE. So I ran the tests again, and using lots
>of different configurations. [...]
My question is: what is measured in this test?
As *I* understand, the program (CoreTest/SysInfo/...) measures the average
time it takes to read certain amount of data from hard disk (and then
calculates transfer rate from that number). So, where is the VL-bus (or
other bus) in this story? The result is the *bare mechanical characteristics*
of the drive (assuming that the interleave is 1:1)!
To be precise, the time measured includes the following:
a. time to program HD controller (negligible);
b. time it takes to seek the requested cylinder/sector (very essential);
c. time it takes controller to read sector from disk into controller's
buffer and verify ECC (depends on spinning rate of the disk and sector
angle);
d. time it takes BIOS (or other driver program) to get the data from
controller's buffer - "REP INSW" (this one depends on bus speed!);
e. pause until next sector is read into controller's buffer (this time
includes "c" for 2nd and other sectors);
(again "d", again "e") - until all sectors are read.
Here "d"+"e" time depends *only* on sector angle and disk spinning rate
but not on bus speed (unless bus speed is so low that it does not allow
1:1 interleave).
So, the benchmark program to reduce time "b" reads larger number of sectors
in a single request. Moreover, to increase accuracy often a number of
reads is performed (sure, from the same sectors, so that no time is spent
for positioning drive's head onto other cylinder) - hence usage of cache
drastically increases "transfer rate".
With cache turned off the result of benchmark is "d"+"e" times - bare
mechanical characteristics. With cache on the result is senseless.
So, it is not surprizing that the results were the same.
>DO NOT BUY LOCAL BUS IDE. It is a *waste* of money.
I'm not going to completely agree - this depends.
Let's return to "e". Under plain DOS in this stage BIOS just checks the
controller status until either the next sector is ready in controller's
buffer or an error occures - this is an idle time. However, under a real
Operating System this time is used for other tasks. So, since "d"+"e"
is constant reducing time "d" one increases "e" and hence improves
effectiveness of processor usage. And *that* is, probably, the case with
VL-bus controller (and a real OS).
Summary: there is no need in VL-bus unless you are running a multitasking
OS.
Suggestion: could one measure times "d" and "e" separately?
Disclaimer: I may be wrong completely or partially, so other opinions
are welcome.
Regards.
Vadim.
Piers Hendrie
>I'm not going to completely agree - this depends.
>Let's return to "e". Under plain DOS in this stage BIOS just checks the
>controller status until either the next sector is ready in controller's
>buffer or an error occures - this is an idle time. However, under a real
>Operating System this time is used for other tasks. So, since "d"+"e"
>is constant reducing time "d" one increases "e" and hence improves
>effectiveness of processor usage. And *that* is, probably, the case with
>VL-bus controller (and a real OS).
>
>Summary: there is no need in VL-bus unless you are running a multitasking
>OS.
>
>Suggestion: could one measure times "d" and "e" separately?
>
>Disclaimer: I may be wrong completely or partially, so other opinions
>are welcome.
>
>Regards.
>Vadim.
>
I thought that IDE controllers did not have the capacity to call back the system when they
have finished processing a request, as is the case with SCSI controllers for example.
This would mean that the CPU must wait for the controller, which in turn waits for the
disk, during this 'idle' time, and hence this period of inactivity is unavoidable and
hence the performance is not a function of the operating system.
I realise that this is probably not true for PS/2 computers whose ABIOS is providing
features to allow the CPU to work during times when it would otherwise be waiting for hardware.
Piers.
Guy Dawson
Response at the top 'cos it's easier!
If you are going to use a multi-tasking OS then you want to use a controller
that does bus mastering. This means that once you have asked the controller
to do the transfer you are free to do other things. This happens after
part A. This is a much bigger saving than is gained by the faster bus in
parts d and e.
Guy
--
-- -----------------------------------------------------------------------------
Guy Dawson - Hoskyns Group Plc.
gu...@hoskyns.co.uk Tel Hoskyns UK - 71 251 2128
gu...@austin.ibm.com Tel IBM Austin USA - 512 838 3377
David Stam
: To be precise, the time measured includes the following:
: a. time to program HD controller (negligible);
: b. time it takes to seek the requested cylinder/sector (very essential);
: c. time it takes controller to read sector from disk into controller's
: buffer and verify ECC (depends on spinning rate of the disk and sector
: angle);
: d. time it takes BIOS (or other driver program) to get the data from
: controller's buffer - "REP INSW" (this one depends on bus speed!);
: e. pause until next sector is read into controller's buffer (this time
: includes "c" for 2nd and other sectors);
: (again "d", again "e") - until all sectors are read.
Finally, someone who knows what they're talking about!
: Here "d"+"e" time depends *only* on sector angle and disk spinning rate
: but not on bus speed (unless bus speed is so low that it does not allow
: 1:1 interleave).
The Quantum LPS240AT has a platter read rate of 3MB/sec on the outside tracks,
and 1.5MB/sec on the inside tracks. The fastest transfer rate I've seen is
1200KB/sec (coretest). I hooked an oscilloscope to the bus during this and
saw the REP INSW doing 1 16-bit transfer every 8 bus cycles (8MHz bus). This
translates to a max rate of 2MB/sec, not the expected 5MB/sec. The IORDY
line was not being asserted by the drive, so it was the AT bus which was
controlling the transfer rate. Can the CPU read the AT bus at 5MB/sec and
store the data in memory at the same time? Maybe only certain chipsets can
do this. Obviously mine (and the other 2 computers I tested this on) can't.
A well designed VLB IDE controller should be able to buffer the reads/writes
and talk to the disk at 5MB/sec (or more). Poorly designed ones may screw
up the 33Mhz <-> 8Mhz buffering and limit themselves to 2MB/sec.
: Suggestion: could one measure times "d" and "e" separately?
I am working on a benchmark to do just that. Also testing the performance
benefit of multiple-sector read/writes (available on some drives, largely
ignored by most OSes). I'll make it available when I'm done.
: Regards.
: Vadim.
David
o o
--------------------oOO-(_)-OOo--------------------------------------------
David Stam Linux: The choice of a GNU generation
st...@netcom.com 386-un*x-X11R5-Openlook-gcc-TeX-FREE!
John Hood
>The Quantum LPS240AT has a platter read rate of 3MB/sec on the outside tracks,
>and 1.5MB/sec on the inside tracks. The fastest transfer rate I've seen is
>1200KB/sec (coretest). I hooked an oscilloscope to the bus during this and
>saw the REP INSW doing 1 16-bit transfer every 8 bus cycles (8MHz bus). This
>translates to a max rate of 2MB/sec, not the expected 5MB/sec. The IORDY
>line was not being asserted by the drive, so it was the AT bus which was
>controlling the transfer rate. Can the CPU read the AT bus at 5MB/sec and
>store the data in memory at the same time? Maybe only certain chipsets can
>do this. Obviously mine (and the other 2 computers I tested this on) can't.
It may not be a so much a question of good or bad design; it could be
a result of the chipset having to introduce wait states to synchronize
the "asynchronous" bus and CPU clocks (we all know that most of the
time the bus clock is derived from the CPU clock, but I'd guess that
most chipsets still treat the bus clock as though it were
asynchronous).
>A well designed VLB IDE controller should be able to buffer the reads/writes
>and talk to the disk at 5MB/sec (or more). Poorly designed ones may screw
>up the 33Mhz <-> 8Mhz buffering and limit themselves to 2MB/sec.
It should also be able to handle drives that can run faster than the 8
MHz timing.
--jh
--
John Hood Cthulhu-- just imagine it!
jh...@smoke.marlboro.vt.us
Richard Krehbiel
> As *I* understand, the program (CoreTest/SysInfo/...) measures the
> average time it takes to read certain amount of data from hard
> disk (and then calculates transfer rate from that number). So,
> where is the VL-bus (or other bus) in this story? The result is
> the *bare mechanical characteristics* of the drive (assuming that
> the interleave is 1:1)!
>
> To be precise, the time measured includes the following:
> a. time to program HD controller (negligible);
> b. time it takes to seek the requested cylinder/sector (very essential);
> c. time it takes controller to read sector from disk into controller's
> buffer and verify ECC (depends on spinning rate of the disk
> and sector angle);
> d. time it takes BIOS (or other driver program) to get the data from
> controller's buffer - "REP INSW" (this one depends on bus speed!);
Indeed, this depends on bus speed. What bus? The VL-bus, or the IDE
bus? Since the data passes through both, the it cannot move any
faster than the slower of the two. The slower of the two busses is
definitely IDE. How fast is it? Since IDE is fundamentally an ISA
bus on a ribbon cable, IDE should have the same bandwidth as ISA.
Therefore, a VL-bus IDE controller will have the bandwidth of ISA. An
ISA bus IDE controller will have the bandwidth of ISA.
How much faster do you think a VL-bus serial port would be?
--
Richard Krehbiel ri...@grebyn.com
OS/2 2.0 will do for me until AmigaDOS for the 386 comes along...
Vadim V. Vlasov
>I thought that IDE controllers did not have the capacity to call back the system when they
>have finished processing a request, as is the case with SCSI controllers for example.
>This would mean that the CPU must wait for the controller, which in turn waits for the
>disk, during this 'idle' time, and hence this period of inactivity is unavoidable and
>hence the performance is not a function of the operating system.
IDE controllers are 100% compatible with standard AT HD controllers and
generate an interrupt (IRQ14) after *each* sector successfully transferred
from disk to controller's buffer. Since most IDEs have buffer larger than
512 bytes there might (this is only my hypotheses) be a way to configure IDE
controller to generate interrupt when the buffer is full or request is
completed - that would decrease interrupt handling overhead for a multitasking
OS.
Back to idle periods. Standard AT BIOS provides means for usage of this idle
time - it generates INT 15h, AX=9000h/9100h at start/end of disk wait periods.
So, usage of this time is possible even under DOS. But do you know a program
that uses it?
Vadim.