Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!intercon!amanda@intercon.UUCP From: amanda@intercon.UUCP (Amanda Walker) Newsgroups: comp.protocols.appletalk Subject: Re: Re: Ethernet vs LocalTalk Message-ID: <09-May-89.125522@192.41.214.2> Date: 9 May 89 16:47:18 GMT References: <1941@ccnysci.UUCP> <278@suna.CMI.COM> <29995@apple.Apple.COM> Sender: news@intercon.UUCP Reply-To: amanda@intercon.UUCP (Amanda Walker) Organization: InterCon Systems Corporation, Sterling, VA Lines: 24 In article <1941@ccnysci.UUCP>, alexis@ccnysci.UUCP (Alexis Rosen) writes: >In article <29995@apple.Apple.COM> desnoyer@Apple.COM (Peter Desnoyers) writes: >> LocalTalk (through a bridge) - 138kbit/s >> EtherTalk (same wire) - 418kbit/s >What I would like to know is why the hell we can't get better performance >with EtherTalk on Macs? This performance is about one twenty-fifth the >nominal speed of EtherNet. Not something to make the speed junky's pulse race. Well, we've seen up to about 1.2mbit/s using vanilla EtherTalk drivers to send & receive packets, so part of the problem is in the higher level protocols. The AppleTalk protocol stack (DDP in particular) is tuned better for LocalTalk than for Ethernet. For example, even though you can send bigger packets on an Ethernet, EtherTalk can't use anything over LocalTalk size, which is 576 bytes (+ headers). That's a performance hit right there. Since AppleTalk as it stands has no notion of fragmentation and reassembly, I don't see a simple way around this. The simplest thing (which is still pretty tricky) would probably be to rewrite .ATP to be able to send ATP transactions in larger chunks, but this might well break a lot of other stuff. Sigh. It'd be nice for future versions of AppleTalk to have something along the lines of TCP/IP's "mtu" and "maxseg" parameters... -- Amanda Walker