Xref: utzoo comp.dcom.lans:4342 comp.protocols.tcp-ip:10255 comp.protocols.tcp-ip.ibmpc:2390
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!apple!sun-barr!newstop!sun!lanta!nn
From: nn@lanta.Sun.COM (Neal Nuckolls)
Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject: Re: TCP Ethernet Throughput (AMD vs. Intel vs. Seeq)
Message-ID: <131792@sun.Eng.Sun.COM>
Date: 14 Feb 90 03:56:19 GMT
References: <2447@ncr-sd.SanDiego.NCR.COM> <582@berlioz.nsc.com> <29138@amdcad.AMD.COM>
Sender: news@sun.Eng.Sun.COM
Lines: 39
Keywords:

In article <29138@amdcad.AMD.COM>, phil@pepsi.amd.com (Phil Ngai) writes:
> In article <29914@sparkyfs.istc.sri.com> rusti@milk0.itstd.sri.com.UUCP (Rusti Baker) writes:
> |"[the LANCE] locks up the memory bus during the transfer
> |thus stalling the processor"
> 
> My guess as to what was meant by this is that they are talking about the
> LANCE requiring 600 ns to perform a memory cycle. That is, a zero wait
> state memory cycle is 600 ns. (I don't know if you can do wait states.
> This is based on my experience 6 years ago.) Although this might not
> have been considered unusual when the LANCE came out in the early 80's,
> 10 MHz processors were only a dream at the time) it may seem slow in
> an age of 25 MHz processors.
> 

Actually, an 8-word LANCE burst requires a full 4.8 us from start
to finish (600 ns/word).  The keyword with ethernet chips is
latency -- not bandwidth.  The bandwidth is easy.  Satisfying
the latency needs for, say, a LANCE, in applications more complex
than your typical PC is difficult.

------
Re: TCP Ethernet Throughput

Memory-to-memory TCP throughput between two SPARCstations 1's in
single user mode over an empty ethernet running SunOS 4.1 using a
32k send/receive window is approximately  1030 Kbytes/s .

Interestingly, the bottleneck in squeezing out the final few
Kbytes/s is the medium itself -- the receiver cannot return window
update (acknowledgment) packets and defers while the transmitter
is sending full 1500 byte ethernet frames back-to-back so the
transmitter runs out of "window" after 32k, then it gets all the
acknowledgments in one flood, short pause, then it transmits the
next 32k.  This type of behavior is a manifestation of CSMA/CD.


neal nuckolls
sun microsystems
nn@sun.com