alexr@xicom.uucp (Alex Laney) (02/08/90)
In article <29000@amdcad.AMD.COM> ncpmont@amdcad.UUCP (Mark Montgomery) writes: >In article <582@berlioz.nsc.com> andrew@dtg.nsc.com (Lord Snooty @ The Giant Poisoned Electric Head ) writes: >><2447@ncr-sd.SanDiego.NCR.COM>, ward@babel.SanDiego.NCR.COM (Ed Ward 2337) : >>> I'm looking for some information comparing the Ethernet throughput of the >>> AMD lance, Seeq 8005, and Intel 82??? controller chips.... >> >>I'd look at National's NIC too - they practically own the Enet market. >>-- >>........................................................................... >>Andrew Palfreyman andrew@dtg.nsc.com Albania before April! > >Whoa, boy! I think that the statement "they practically own the Enet >market" is a bit rash. Check with IBM, DEC, SUN or 3COM or look inside their >boxes. I think you'll find that there are about twice as many AMD LANCE, SIA >and XCVR chips in them as all those other manufacturers have sockets combined. >"LOOK AGAIN" to quote the T.I. speak n' spell chip. Mark The figure is: about 85% of the Ethernet chipset market is supplied by Nat. Semi. Surprising but true ... I know for certain that Western Digital and others use the Nat. Semi chipset. How many chips does DEC use compared to the IBM PC and compatible market( Novell, etc.)? It's an independent figure from Dataquest or some organization like that. -- Alex Laney, Xicom Group, National Semiconductor, Ottawa, Canada (613) 728-9099 uunet!mitel!sce!xicom!alex (alex@xicom.uucp) Fax: (613) 728-1134 "You save time, increase the amount of work done and it is easy."
rusti@milk0.itstd.sri.com (Rusti Baker) (02/10/90)
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"
ncpmont@amdcad.AMD.COM (Mark Montgomery) (02/10/90)
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
grr@cbmvax.commodore.com (George Robbins) (02/12/90)
In article <29914@sparkyfs.istc.sri.com> rusti@milk0.itstd.sri.com.UUCP (Rusti Baker) writes: > > 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" Again, this is not neccessarily an attribute of the Lance chip, but rather how a particular interface/system implements the Lance DMA/memory interface. A different interface might implement a (logically) dual ported buffer memory or other scheme and thus avoid this particular constraint. Clearly indentifying the thruput constraints for each of the major ethernet chipsets (let along their common instantiations) would be a major task. Chip selection is usually done on the basis of cost, familiarity, ease of interface and sometimes even avoidance of known problems... -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
phil@pepsi.amd.com (Phil Ngai) (02/13/90)
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. Any DMA device will lock up the memory bus, the question is how long? The people who wrote your quote probably thought 600 ns was too long. This is the kind of thing that a new device would probably do better. I am not an official or unofficial spokesman for the company. This is only my opinion. Copyright 1990 by Phil Ngai. You may only distribute with the above disclaimer. -- Phil Ngai, phil@amd.com {uunet,decwrl,ucbvax}!amdcad!phil When guns are outlawed, only governments will have guns.
rusti@milk0.itstd.sri.com (Rusti Baker) (02/13/90)
Thanks to Mark Montgomery and George Robbins for clarification of the problem of characterizing the performance of a chip set without considering the interface/system. > 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 I was intrigued by the use of the word "stalling", versus "blocking" etc. I had interpreted the remark in the article to mean that there was something else going on (like the DMA had some other side effect). Since the authors did not elaborate, I was curious.
nn@lanta.Sun.COM (Neal Nuckolls) (02/14/90)
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
Andy.Linton@comp.vuw.ac.nz (Andy Linton) (02/20/90)
There have been a number of articles on the problems with the LANCE. Has anyone any idea if this is used on the MICOM-Interlan boards, NI5010 and NP600A. I'm trying to track down a problem with transfer rates on machines using these boards. Also there seems to be some debate about whether the 3-Com boards use the LANCE. Thanks andy -- SENDER = Andy Linton EMAIL = Andy.Linton@comp.vuw.ac.nz PHONE = +64 4 721 000 x8978