Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!saqqara.cis.ohio-state.edu!elwell From: elwell@saqqara.cis.ohio-state.edu (Clayton Elwell) Newsgroups: comp.protocols.appletalk Subject: Re: TOPs and KIP? Message-ID: <13896@tut.cis.ohio-state.edu> Date: 22 May 88 20:16:34 GMT References: <8805181532.AA00852@apatosaur.cis.ohio-state.edu> <8805201121.AA07033@columbia.edu> Sender: news@tut.cis.ohio-state.edu Organization: The Ohio State University Dept of Computer and Information Science Lines: 33 cck@CUNIXC.COLUMBIA.EDU (Charlie C. Kim) writes: [good analysis of the EtherTalk choking problem in KIP 1/88] It is possible to modify the ethernet driver to handle tightly spaced packets far better; however, it is not possible to do this without killing off the localtalk service. I'd change that to "it is not EASY to do this ...". The Kinetics EtherTalk gateway code does not seem to have this problem. The handling of the Ethernet controller in the KIP gateway is pretty elementary, from my reading of the source. Also, this isn't all that's happening. We are seeing a repeatable 50% packet loss through *either* IP or EtherTalk, if the EtherTalk option is turned on. If it is not turned on, performance goes back up to normal... [Actually, the contention is probably bus/memory - the 82586 ethernet controller is effectively a small cpu that accesses the bus/memory independently of the main cpu (68008) and is probably fast enough to block out the 68008 long enough to mess up the lap timing]. I haven't looked at the code that talks to the SCC, but it might be possible to get it to do more of the work. In any case, I'd suggest talking to Kinetics to see if they are willing to "share their secrets," as it were :-). If the new KIP actually allowed usable performance on EtherTalk, life would be pretty cool. -=- Clayton M. Elwell -=- "Gee, the Captain's vanished utterly so we'd better beam down the second-in- command to exactly the same coordinates to see what happened to him!"