Xref: utzoo comp.dcom.lans:4316 comp.protocols.tcp-ip:10215 comp.protocols.tcp-ip.ibmpc:2374
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!amdcad!ncpmont
From: ncpmont@amdcad.AMD.COM (Mark Montgomery)
Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject: Re: TCP Ethernet Throughput (AMD vs. Intel vs. Seeq)
Keywords: Van Jacobson, Steve Bellovin
Message-ID: <29116@amdcad.AMD.COM>
Date: 10 Feb 90 04:59:57 GMT
References: <2447@ncr-sd.SanDiego.NCR.COM> <582@berlioz.nsc.com> <29000@amdcad.AMD.COM> <29914@sparkyfs.istc.sri.com>
Reply-To: ncpmont@amdcad.UUCP (Mark Montgomery)
Organization: Advanced Micro Devices
Lines: 18

In article <29914@sparkyfs.istc.sri.com> rusti@milk0.itstd.sri.com.UUCP (Rusti Baker) writes:
>I would be interested in seeing any type of discussion of 
>the behaviour of the chips mentioned in this thread.
>E.G. Clark, Jacobson et al provided this insight into the 
>behavior of the LANCE in their June 1989 IEEE Comm.  article: 
>"[the LANCE] locks up the memory bus during the transfer
>thus stalling the processor"

Yes, and how many times have we seen in this group and protocols people
asking if anybody knew why their 3c5xx board was locking up their
system.
	Well, 3c5xx's don't have LANCE's on them, they have N__ chips.
	Also if you'll re-read the article you'll see that what they
	were saying was that the LANCE was "stalling" the cpu while
	it did dma of the packet directly to memory.  Can't do that
	with an XYZ chip.  Of course you could have the cpu do the
	transfers or you could build a cache if you'd rather.
				Mark