Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ucla-cs!cit-vax!elroy!jplgodo!wlbr!scgvaxd!trwrb!sdcrdcf!darrelj
From: darrelj@sdcrdcf.UUCP (Darrel VanBuer)
Newsgroups: comp.dcom.lans
Subject: Re: Higher speed LANs ?
Message-ID: <4704@sdcrdcf.UUCP>
Date: Wed, 24-Jun-87 11:11:48 EDT
Article-I.D.: sdcrdcf.4704
Posted: Wed Jun 24 11:11:48 1987
Date-Received: Fri, 26-Jun-87 07:09:53 EDT
References: <541@houxa.UUCP>
Reply-To: darrelj@sdcrdcf.UUCP (Darrel VanBuer)
Organization: Unisys - System Development Group, Santa Monica
Lines: 46

In article <541@houxa.UUCP> mel1@houxa.UUCP (M.HAAS) writes:
>Is anyone working on higher speed LANs?  We have lots of conversation
>What are the issues that keep us down at such low rates?  The disks
>themselves are now in the 500K to 2Meg bytes per second range. 
>Backplanes and memory are up in that range.  Certainly, interface
>logic can go that fast (it does to disks, why can't it to LANs?).
>
>In theory one can stuff bits down an Ethernet at 1,500K bytes per
>second.  Why is it such a struggle to get 200K bytes per second
>onto it?
>
>   Mel Haas  ,  odyssey!mel

There are two (almost) fundamental problems:
Few computers can do interesting amounts of data processing faster than that
(e.g. 10 Mbit/sec = 30K lines of code to compile per second.  Even raw
images are only a few million bits, so you can send faster than you can look
at them (it's not fast enough for moving pictures, ala TV, but LANs aren`t
trying to be cable TV).
The second problem is that few operating systems can schedule more than a
few hundred I/O activities per second.  In our experience, a VAX 780 running
4.2 saturates near 100 to 150 packets per second in PUP or TCP/IP, almost
independent of packet size.  Data throughput thus can range from a low of a
few thousand bits per second with one byte of user data per packet (and
under 100K bits per second on the Ether), to maybe 2 million bits per second
between processes writing and reading the SAME buffer (i.e. absolutely NO
data processing).  The VAX CPU is the bottleneck (at least with the existing
networking software).  It does NOT seem to be a misimplementation, since
Xerox equipment running different protocols and different hardware (with
microcode support) and totally different system software has similar
performance.
Every measurement of networks in real usage environments (not the stress
tests you write papers and claims for) show (Ethernets) with a few dozen
workstation to VAX size machines show network utilization of a few hundred
thousand bits per second in prime time, with occasional transients up to a
million bits per second.  Our network has collisions for less than 1% of
packets sent.
When we get to the point where we have a Cray-1 on every desk and all take
up data intensive jobs like CAD/CAM and image processing, faster networks
will be necessary; right now they just drive up the cost to increase the
network idle time from 90% to 95 or 99%.

-- 
Darrel J. Van Buer, PhD; unisys; 2525 Colorado Ave; Santa Monica, CA 90406
(213)829-7511 x5449        N6PFO/AA        darrel@CAM.UNISYS.COM   or
...{allegra,burdvax,cbosgd,hplabs,ihnp4,sdcsvax}!sdcrdcf!darrelj