lindsay@gandalf.cs.cmu.edu (Donald Lindsay) (12/11/90)
In article <PCG.90Dec10185727@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >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. I seem to recall a typical loaded Unibus getting rather under 1 MB/s. The same for Ethernet, come to think of it. The inadequacy of the current situation is demonstrated by the Creo optical drive, which puts a terabyte on a single reel. With its 3 MB/s SCSI interface, it takes **four days** to read one tape! [In Creo's defence, they have a fast scan mode.] -- Don D.C.Lindsay .. temporarily at Carnegie Mellon
pcg@cs.aber.ac.uk (Piercarlo Grandi) (12/13/90)
On 11 Dec 90 15:47:43 GMT, lindsay@gandalf.cs.cmu.edu (Donald Lindsay) said:
lindsay> In article <PCG.90Dec10185727@odin.cs.aber.ac.uk>
lindsay> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
pcg> As an IO bus the ISA bus and Unibus and QBUS are perfectly adequate
pcg> for the most common minicomputer applications. After all the
pcg> fastest IO buses commonly available (IPI etc. are *expensive*) do
pcg> not get much over 1-2MB/sec., and the ISA bus runs to 5-6MB/sec.
pcg> You can have multiple SCSI adapters on an ISA bus and you dont'
pcg> saturate it.
lindsay> I seem to recall a typical loaded Unibus getting rather under 1 MB/s.
Nominally the Unibus, which is 16 bit parallel bus, can do around
5MB/sec. I think that is actually fairly credible. Think of it -- it was
used as the memory bus of various PDP-11s that could do nearly 1 MIPS,
and move 32 bit per instruction (16 of instruction, 16 of data). The
Unibus was not the bottleneck; it could sustain memory-to-memory copies,
i.e. 3-4 MB/sec. on something like an 11/45, fairly well. You could get
poor Unibus usage with certain peripherals (I seem to remember the RK07)
that had faulty microcode that kept the bus busy for twice longer than
necessary, or others that used inefficient byte transfer modes; but a
Unibus was able to run one 0.5-1 MIPS 16 bit CPU and two SMD disks and a
tape quite well in practice.
lindsay> The same for Ethernet, come to think of it.
The ethernet is a contention based 1 bit wide channel. Quite unlike a
Unibus. On the other hand a lot of people try to use the Ethernet as a
shared IO bus for distributed multiprocessors connnecting a couple dozen
10 MIPS processors and half a dozen SCSI disks (a common workstation LAN
is a distributed multiprocessor in terms of load), and then complain...
lindsay> The inadequacy of the current situation is demonstrated by the Creo
lindsay> optical drive, which puts a terabyte on a single reel. With its 3
lindsay> MB/s SCSI interface, it takes **four days** to read one tape! [In
lindsay> Creo's defence, they have a fast scan mode.]
Ah yes, but there are then even more ridiculous stories. How long does
it take to backup one of the currently existing 1GB WORMs? Please have a
look at their peak transfer rate. How many people buy 2 600MB
winchesters and try to back them up on a 90KB/sec. QIC tape? How many
people try to backup a dozen GB to a 246KB/sec. Exabyte over a 1MB/sec.
(if empty) Ethernet?
There are even drives, magnetic or not, whose mean undetected error rate
is of the same order as their capacity, so virtually guaranteeing that
you get an undetected error every time you make a copy of them. After
all even a fairly respectable undetected error rate of 1 in 10^12 is
usually expressed in bits. Make some calculations...
Many high density recording techniques have abject transfer rates
because the material or the recording head cannot do many state changes
per second. This means that yes you can record a load of data on them,
but it takes forever, and backups are out of the question. Just an
example: if you have a friend with a NeXT, try to measure the write rate
of a floptical (the access time is the least of the problems you will
discover...).
Spoiler: if you get rates such as 2 or 3 KB/sec (no, I have not
left out any zeroes here) don't be surprised.
I think that if holostores keep their promise, or even just
ferroelectric memory does, we will find the land of milk and honey.
Hey, *anything* but moving arm technology or magnetic recording. Disk
drives are a very very poor make do.
--
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.uklindsay@gandalf.cs.cmu.edu (Donald Lindsay) (12/14/90)
In article <PCG.90Dec12174320@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >> I seem to recall a typical loaded Unibus getting rather under 1 MB/s. >The >Unibus was not the bottleneck; it could sustain memory-to-memory copies, >i.e. 3-4 MB/sec. on something like an 11/45, fairly well. I believe I was wrong: I should have said 1 MW/s, which is 2 MB/s. A device 'way out the end of a long daisy chain could spend around a microsecond on that "400 ns" cycle. This can be squared with your 3-4 MB/s by noting that the 11/45 had a fast CPU-memory path as well as its Unibus. >There are even drives, magnetic or not, whose mean undetected error rate >is of the same order as their capacity, so virtually guaranteeing that >you get an undetected error every time you make a copy of them. After >all even a fairly respectable undetected error rate of 1 in 10^12 is >usually expressed in bits. Good point! Creo's 1 TB optical tape holds 10^12 bytes and has "fewer than 1 in 10^12" bit errors. The pessimistic reading is as "fewer than 8 mistakes per reel". It doesn't wash to say that one is storing (say) images, where errors will be unnoticable. Images are usually stored in some compressed form, and decompression should be a pretty good error magnifier. Rather than expecting perfection, we should probably expect systems to have selectable, adjustable amounts of protection. -- Don D.C.Lindsay .. temporarily at Carnegie Mellon