IO buses, memory waste

[Piercarlo Grandi]

On 5 Dec 90 22:11:51 GMT, pst at ack.Stanford.EDU (Paul Traina) said:

pst> You're absolutely right and I stand corrected.  The UNIBUS itself
pst> _is_ a pig compared to modern bus'es.

Not really. Again we must make the distinction between the memory bus
and the IO bus. As an IO bus the ISA bus and Unibus and QBUS are
perfectly adequate for the most common minicomputer applications. After
all the fastest IO buses commonly available (IPI etc. are *expensive*)
do not get much over 1-2MB/sec., and the ISA bus runs to 5-6MB/sec. You
can have multiple SCSI adapters on an ISA bus and you dont' saturate it.

As a memory bus the ISA bus and UNIBUS and QBUS are simply not adequate
beyond CPU speeds of 1 MIPS (i.e. anything beyond an 11/73). But nobody
uses them as memory buses nowadays, except the fools that do EGA/VGA
based graphics (where however the real ptoblem is not the bus bandwidth,
but the very narrow bandwidth of the frame buffer, which is 1MB/sec if
all goes well, and 2MB/sec. if you have  16 bit wide video RAM).

pst> However, you're not scaling your I/O performance with your CPU.
pst> You're talking about blowing CPU performance out of the water (386
pst> vs 11/70) 

4-8 MIPS vs 1 MIP? We are within one order of magnitude... And software
bloat and misdesign has eaten most of that anyhow. This may seem
cynical :-). But yes, I am prepared to concede that improvemnt in CPU
speeds has not been matched by that of the memory subsystem (and not
just IO, actually!), but this is is not the fault of insufficient IO bus
bandwidth on machiens at the workstation/mini level.

pcg> but you're still talking about comparable I/O (even if we go
pcg> MASSBUS and 780).  Where's the exponential performance increase in
pcg> I/O?

It's not there, but it's not really a bus issue. Ah damn, storage
capacity (at all levels of the hierarchy) has increased, but not so much
latency (seek and rotational) and bandwidth.

Latency has hardly improved at all, while bandwidth has improved a bit
more (but only for *expensive* systems), e.g. SCSI-2 synchronous
transfer and 16/32 bit wide bus, E-SMD, IPI, drive arrays, but for most
timesharing use latency is what really matters.

pst> You're welcome to fix the bsd VM subsystem

Actually the BSD VM system needs no fixing; it was designed, quite well,
by a very capable and talented guy, for a 512KB (later 2MB) machine
running processes with an average working set of a few dozen KB.  For
current loads (dozen of MBs, wrokings sets of many MBs) it ought to be
*rewritten* (and it has been, in many places).

As to Sun (that you mention is passing :->), the problems with them are
mostly in their MMU architectures (when will they able to get one
right?), not just with the SunOS inane idea of using LIFO replacement
policies where FIFO reference patterns can be easily predicted (and a
few other monstrosities -- I have all of them neatly discussed in an
article that I will eventually post).

pst> (actually, it has been fixed).

Maybe in System V.4? I hope so! Turning to AT&T USG/USL, System V.3
still does, on paged machines with a fast CPU, expansions swaps: when
there are no free pages, odds are that it is the process that is trying
to expand that will be swapped out to free some pages, which of course
is idiotic, and results in swap trashing, because that same process is
most likely to be swapped in again soon, because it was active, thus
most likely recreating the situation over and over again, as the
processes expands until it reaches its stable size.


Note that both the SunOS and System V.3 problems are easily understood,
easily predicted, and yet nothing has been done about them -- well,
adding RAM so that the broken pager (Sun) or swapper (SysV) is never
exercised is evidently cheaper than finding an OS designer to understand
and fix them. It all really depends on the relative scarcity of RAM vs.
OS engineers in the two countries that do them :-). Or not? If not,
where are all the OS people that can for example design a decent VM
susbsystem?

Bah, bah, bah. Sorry to have unloaded again some of my pet peeves.
--
Piercarlo Grandi                   | ARPA: pcg%uk.ac.aber.cs at nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg at cs.aber.ac.uk