Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!samsung!munnari.oz.au!wcc!tom From: tom@wcc.oz (Tom Evans) Newsgroups: comp.protocols.appletalk Subject: Re: Enhanced LocalTalk (was: Mac Booster Modules) [long] Message-ID: <536@wcc.oz> Date: 20 Dec 89 07:57:45 GMT References: <6662@imag.imag.fr> <24772@cup.portal.com> <9241@hoptoad.uucp> <9342@hoptoad.uucp> Organization: Webster Computer, Melbourne, Australia Lines: 122 In article <9342@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > >> A rather vague and misleading phrase. Yes, LocalTalk Macs will step on > >> FlashTalk packets, requiring retransmission. However, this does not > >> cause any serious problems, other than some performance degradation. > > In article <526@wcc.oz> tom@wcc.oz (Tom Evans) writes: > >Some? SOME!!!??? How about 95% degradation being "some"? > > Brent Noorda did measurements on FlashTalk at TOPS that were meant for > internal distribution, rather than press releases. They did show some > degradation, but nowhere near this magnitude. LocalTalk follows rules, and these rules have consequences. If TOPS have got around the consequences (listed in my analysis). I would like to know how. If I've missed something obvious I'd like to know too. Ten minutes with a pair of FlashBoxes and a logic analyser'd do it. > >Machine "A" and "B" communicating using ATP - file copy operation at > > Are these real figures or just some that seem correct? Have you > actually done these timings? Not meaning to seem snide; it's just that > you didn't say. True. Snide away. I deserve it. It's a gedunkenexperiment based on the real work I did analysing the packet-drop problems I was having and I should have said so. If someone would like to employ (and pay) me just to prove everything I say on the net, when can I start? :-). > I don't think "it seems right" is any basis for conclusions about network > speed; the real world is never quite the way we imagine it will be. Agreed, but whenever I've found the real world to be at odds with my imaginings, it's usually worth investigating, as either: a. I've missed something and I learn, or b. I've found another bad bug in some part of the real world masquerading as a performance problem and I fix it. It's no more "seems right" than: >> The real issue with these acceleration products is that they simply >> ... >> Network protocol performance is >> generally bounded far more by per-packet overhead on the interpreting >> machines than by the raw bandwidth on the network. If there's an >> enormous difference -- for instance, the factor of roughly 30 between 43 ^^ >> LocalTalk and EtherNet -- then you will see much better performance on >> the faster network, but when the differences are small, such as the >> factor of 3 between LocalTalk and either FlashTalk or DaynaTalk, the >> per-packet overhead will continue to predominate and any actually >> performance improvements will be nearly indetectable. Doesn't scan. If I reduce my transmission time from 1 (40/40) to 1/3 (13/40) and don't see any improvement, why should going to Ethernet at 1/40 make any difference? I sped things up by 27/40th the first step, and only 12/40th the second. The improvement to EtherTalk should only be 12/27th. of "indetectable". Is the LocalTalk-specific overhead so much more than the EtherTalk one? Is the Mac able to overlap execution with the Ethernet controller THAT well? There's a real story here somewhere. > (I'm not sure, but I assume that a > FlashTalk-equipped Mac will avoid stepping on LocalTalk packets even > when it has to run at LocalTalk speeds.) I would hope so, but wonder how. The FlashBox must be performing the "CarrierSense" function because I can't see how you could make the SCC do it. > But let's grant your figures for the sake of argument. So what do you > intend to do about it? Either: a. Not use FlashTalk, and either i. Live with it, or ii. Buy more Routers - less macs/net, or require that b. All the "fast" stuff is on the other side of something that can isolate FlashTalk (like a repeater). Either way it makes network management and site planning a lot more difficult. > In any case, the obvious > solution is to improve your timeouts; make them 0.5 seconds and post > the measurements, s'il vous plait. Love to. Where are they, in the Chooser or Control Panel? Nope, they're buried in Apple's system code somewhere. Not my favourite territory. The timeouts for LaserWriters may be burned into the LaserWriter ROMs for all I know. The TREL stuff is wired into AppleShare. > >Let's say the packet that gets clobbered is an ATP TREL packet (the > > Again, these timeout values are tuned badly. Don't tell me, tell Apple :-). I (as a user) can't change them. Note that they're INCREASING the TREL timeout from 30 seconds to (optionally) 30s, 1 minute, 2m, 4m and 8m in Phase 2. Lose one TREL on 8 minutes, take a lunchbreak :-(). > >Maybe the real advantage is that the physical cable can now handle THREE > >times the volume of traffic. > Kind of a strange thing to say right after complaining about the number > of collisions. The collisions should occur only when you mix traffic types. If you need the throughput and can equip all devices then it looks like a good solution. If this is boring others to tears, feel free to tell me to shut up. --------- Tom Evans tom@wcc.oz.au | Webster Computer Corp P/L | "The concept of my 1270 Ferntree Gully Rd | existence is an Scoresby, Melbourne 3179 | approximation" Victoria, Australia | 61-3-764-1100 FAX ...764-1179 | D. Conway 2109 O'Toole Avenue, Suite J SAN JOSE CA 95131 - 1303 CALIFORNIA 1-408-954-8054 FAX 1-408-954-1832