pcg@cs.aber.ac.uk (Piercarlo Grandi) (12/11/90)
On 5 Dec 90 22:11:51 GMT, pst@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@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk