Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!agate!ucbvax!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.unix.admin
Subject: Re: IRC Net Bandwidth (was IRC and Security)
Message-ID: <11813@dog.ee.lbl.gov>
Date: 4 Apr 91 23:14:39 GMT
References: <703@seqp4.UUCP> <16929:Mar2121:19:0091@kramden.acf.nyu.edu> <704@seqp4.UUCP> <27773:Apr420:02:0691@kramden.acf.nyu.edu>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 26
X-Local-Date: Thu, 4 Apr 91 15:14:39 PST

In article <27773:Apr420:02:0691@kramden.acf.nyu.edu>
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>I believe Chris's comments confirm that routers are just that poor.

`Were', not `are'.  (No doubt some are still in place; it takes time
to throw out broken equipment and software that is in production use.)

I have some more recent information.  Old NSS routers took 6 to 8 ms.
of cpu time to forward each packet, due to excessive stupidity in the
device driver code.  (The routing time was too small to measure in
these systems; `Almost all the per-packet cpu time was spent in device
drivers'.  In addition the old routers added store-and-forward delays
at each T1-to-NSS boundary, because the T1 boards had onboard 386s doing
copies in and out of onboard buffers.  [Better than Z8s, I guess. :-) ])

The new CNSS/ENSS T3 routers are better.  My source has no timings yet
but `we had no trouble using the T3 backbone to saturate a 10Mb/s
ethernet from a machine 1000 miles away'---saturate here means get
approximately 1 MB/s (8 Mb/s) actual data transfer, host-to-host.
(One host was a Cray, the other a Sun SparcStation, both running
experimental software.)  In other words, the problems may not be
completely fixed yet, but they have definitely receded a comfortable
distance.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov