🚀 go-pugleaf

On 2 Sep 91 13:51:20 GMT, cpcahil@virtech.uucp (Conor P. Cahill) said:

cpcahil> pcg@aber.ac.uk (Piercarlo Antonio Grandi) writes:

pcg> Same goes for EISA SCSI disk controllers (the most expensive SCSI
pcg> disks top out at 4MB/s, and most cannot do more more than 1.5MB/s
pcg> off the platter). In practice EISA is only needed for very high
pcg> speed graphics (good luck with that) and for disk arrays, or,
pcg> theoretically, for very high bandwidth tapes.

cpcahil> Throughput is not the only evaluation factor for a disk
cpcahil> controller.  Another factor, which is where a good EISA
cpcahil> controller will shine, is the amount of time the bus is tied up
cpcahil> transferring that 4MB/s.

Latency then perhaps matters. But in practice not a lot...

cpcahil> You yourself said that the theoretical max for the ISA bus was
cpcahil> between 5 and 6 MB/s.  4MB/s is appox 80% of the theoretical
cpcahil> max.

Of course, but this is nearly irrelevant. Almost nobody keeps their SCSI
bus running at its top rated bandwidth continuously (not even Adaptec,
which stay off the bus for some programmable fraction of the time).

In particular disk access tends, in normal operation, to be bursty (the
effect of caching and paging, and then of intervening seeks).

Also, most disks currently available don't do much more than 1.3MB
sustained, so having two such disks gives you, if both are active
together, an instantaneous bandwidth of 2.6MB/s, but on average they
will not be both active together, and theat will not in acase last long.

In practice 5-6MB/s is many times than the *average* bandwidth
required, and it is twice the highest instantaneous load you can expect
to see in a small to medium general purpose timesharing system.

cpcahil> With a good EISA controller that same 4MB/s can take up only
cpcahil> 12% of the theoretical max, thereby freeing the bus up for
cpcahil> other operations.

The problem is that, except for very large systems running very large
loads, or particular cases, there are no other operations.

All CPU memory access, the real pig, is via a private bus, and only
tapes, disks, communications and framebuffers use the ISA bus, and their
combined *average* utilization is nowhere its saturation point, and
their *peak* is also accomodated more or less easily.

pcg> First of all, the good news: as I have said almost any modern
pcg> Ethernet card will deliver substantially all of the Ethernet
pcg> bandwidth, and this bandwidth is at worst one fifth of the ISA bus
pcg> bandwidth, so you don't need any EISA

cpcahil> Giving up 20% of the bus bandwidth just to handle ethernet i/o
cpcahil> sounds like a good reason to go with EISA.  20% is alot of the
cpcahil> system.

Yes, but you are not transferring 1MB/s constantly thru your Ethernet
adapter, I hope. And if you are, then most people have pretty low
average Ethernet adapter utilizations.


Quite surprisingly :-) the highest bandwidth user is likely to be the
frame buffer: SVGA cards, which are pretty slow as frame buffers go, can
require 2MB/s, and, if you are doing image processing, sustainedly. But
a 2MB/s video card will almost surely need a 2MB/s disk/tape subsystem,
and this is not the sort of application that I would do with ISA, I
would definitely do it with EISA. I would also use EISA for largish
(more than (perhaps half) a dozen users) timesharing.
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk