MacUserLabs@cup.portal.com (Stephan - Somogyi) (12/07/89)
bordier@imag.imag.fr (Jerome Bordier) writes: >In November BYTE (p.219), Tom Thompson states that "the faster >DaynaTALK and FlashBox modules can coexist with devices running at the >slower, standard LocalTalk transfer rate, such as Macs without >enhanced connectors, laserprinters, and certain network bridges." Is >it true inside one LocalTalk zone ? (my local distributor told me that >any Mac in one zone must have the booster module). As loath as I am to plug my own stuff on the net, it might be a good idea if you took a look at our Ocober issue; I did a piece on the enhanced LocalTalks. The quick answer to your question is that non-Mac LocalTalk devices can't be used at enhanced LocalTalk speeds, unless they specificically support enhanced LocalTalk. I can't think of anything out there that does this. StarControllers will work, but that's about it (as far as I can remember). Non-enhanced nodes usually can't see when enhanced nodes are transmitting, and will therefore step all over enhanced traffic. This, obviously, messes things up a bit. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Stephan Somogyi MacUserLabs@cup.portal.com NetWorkShop Coord. or MacUser ...{apple|uunet|sun}!cup.portal.com!MacUserLabs The MacUser NetWorkShop - home of the LocalTalk backbone Any opinions expressed above are mine.
tim@hoptoad.uucp (Tim Maroney) (12/10/89)
bordier@imag.imag.fr (Jerome Bordier) writes: >>In November BYTE (p.219), Tom Thompson states that "the faster >>DaynaTALK and FlashBox modules can coexist with devices running at the >>slower, standard LocalTalk transfer rate, such as Macs without >>enhanced connectors, laserprinters, and certain network bridges." Is >>it true inside one LocalTalk zone ? (my local distributor told me that >>any Mac in one zone must have the booster module). Yes, it is true, at least of FlashTalk. FlashTalk Macs can coexist with LocalTalk Macs. I don't know about DaynaTalk. Your distributor done you wrong. In article <24772@cup.portal.com> MacUserLabs@cup.portal.com (Stephan - Somogyi) writes: >The quick answer to your question is that non-Mac LocalTalk devices >can't be used at enhanced LocalTalk speeds, unless they specificically >support enhanced LocalTalk. I can't think of anything out there that >does this. StarControllers will work, but that's about it (as far as I >can remember). Obviously, non-upgraded Macs can't use the higher speeds. >Non-enhanced nodes usually can't see when enhanced nodes are >transmitting, and will therefore step all over enhanced traffic. This, >obviously, messes things up a bit. 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. The real issue with these acceleration products is that they simply don't deliver much extra performance. Even between two accelerated Macs on the same network, you'll be lucky to get 1.5 speedup, much less the three times one would expect from a naive application of the network bandwidth improvement. 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 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. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "God must be a Boogie Man." -- Joni Mitchell
tom@wcc.oz (Tom Evans) (12/18/89)
In article <9241@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > bordier@imag.imag.fr (Jerome Bordier) writes: > >>In November BYTE (p.219), Tom Thompson states that "the faster > >>DaynaTALK and FlashBox modules can coexist (with Macs not so > >> equipped) > >> > >> (my local distributor told me that > >>any Mac in one zone must have the booster module). > > Yes, it is true, at least of FlashTalk. FlashTalk Macs can coexist > with LocalTalk Macs. I don't know about DaynaTalk. Your distributor > done you wrong. Listen to your distributor (see below). > In article <24772@cup.portal.com> MacUserLabs@cup.portal.com (Stephan > - Somogyi) writes: > >Non-enhanced nodes usually can't see when enhanced nodes are > >transmitting, and will therefore step all over enhanced traffic. This, > >obviously, messes things up a bit. > > 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. Some? SOME!!!??? How about 95% degradation being "some"? I've had to cope with a network that was having "some" packets stepped on, and it wasn't pretty. Let's put some real numbers to it. Machine "A" and "B" communicating using ATP - file copy operation at say 20kbytes/sec. This corresponds to 40 packets/second, all maximum length, and taking up 30% of the FlashTalk bandwidth at 700,400 bits/sec. We now talk from a slow Mac to a LaserWriter, neither of which can see the high speed traffic and stands a 30% chance of killing a fast packet per slow packet. We're running at a reasonable PAP rate of 10 packets per second. We are now killing Fast packets every 0.3 seconds or so. This incurs a 2 second timeout-retry from ATP. We're now sending 12 fast packets in 0.3 seconds and getting stomped for 2 seconds instead of sending 40 per second. 12/2.3 : 40/1 is an 87% slowdown. Some? Let's say the packet that gets clobbered is an ATP TREL packet (the ATP XO sequence is TREQ, TRSP, TREL). Between 10% and 30% of our packets are TREL's (but they're shorter than the data packets - about 30 bytes). For CAP, each TREL dropped incurs a 30 second stall - not a nice thing to witness. With AppleShare, you have two listeners on the socket, so you can drop ONE TREL per 30 second period without penalty. Or else you get the difference. With this added, you're probably up to 90% to 95% performance degradation. And that was with ONE FlashTalk session and ONE LocalTalk session. Jerome's distributor knew what he was talking about. > The real issue with these acceleration products is that they simply > don't deliver much extra performance. Even between two accelerated > Macs on the same network, you'll be lucky to get 1.5 speedup, much less > the three times one would expect from a naive application of the > network bandwidth improvement. Maybe the real advantage is that the physical cable can now handle THREE times the volume of traffic. Like three times as many Macs performing simultaneous data transfer before the net clogs up. Think of it as the difference between a one-lane and a three-lane road. Not much difference at 2:00am (when programmers go to work :-), but a lot of difference to us ordinary folk during the rush hour. --------- Tom Evans tom@wcc.oz.au | Webster Computer Corp P/L | "The concept of my 1270 Ferntree Gully Rd | existence is an Scoresby VIC 3179 | approximation" 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
tom@wcc.oz (Tom Evans) (12/18/89)
In article <24772@cup.portal.com> MacUserLabs@cup.portal.com (Stephan - Somogyi) writes: >The quick answer to your question is that non-Mac LocalTalk devices >can't be used at enhanced LocalTalk speeds, unless they specificically >support enhanced LocalTalk. I can't think of anything out there that >does this. StarControllers will work, but that's about it (as far as I >can remember). No other devices supporting FlashTalk? Not for want of trying. I've been trying since May to get details from Tops so that we could add FlashTalk support to our four-port LocalTalk/Ethernet gateway. Might be useful - FlashTalk speed straight through to Ethernet? Slow devices on 1 (or 2 or 3) ports, fast ones on the other 3 (or 2 or 1). Possibly useful device? I never heard back from them. We're still interested. Hello? --------- Tom Evans tom@wcc.oz.au | Webster Computer Corp P/L | "The concept of my 1270 Ferntree Gully Rd | existence is an Scoresby VIC 3179 | approximation" 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
tim@hoptoad.uucp (Tim Maroney) (12/19/89)
bordier@imag.imag.fr (Jerome Bordier) writes: >> >>In November BYTE (p.219), Tom Thompson states that "the faster >> >>DaynaTALK and FlashBox modules can coexist (with Macs not so >> >> equipped) >In article <9241@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: >> Yes, it is true, at least of FlashTalk. FlashTalk Macs can coexist >> with LocalTalk Macs. In article <24772@cup.portal.com> MacUserLabs@cup.portal.com (Stephan - Somogyi) writes: >> >Non-enhanced nodes usually can't see when enhanced nodes are >> >transmitting, and will therefore step all over enhanced traffic. This, >> >obviously, messes things up a bit. Timbo: >> 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. >I've had to cope with a network that was having "some" packets stepped >on, and it wasn't pretty. Let's put some real numbers to it. > >Machine "A" and "B" communicating using ATP - file copy operation at >say 20kbytes/sec. This corresponds to 40 packets/second, all maximum >length, and taking up 30% of the FlashTalk bandwidth at 700,400 bits/sec. >We now talk from a slow Mac to a LaserWriter, neither of which can see >the high speed traffic and stands a 30% chance of killing a fast packet >per slow packet. We're running at a reasonable PAP rate of 10 packets >per second. We are now killing Fast packets every 0.3 seconds or so. >This incurs a 2 second timeout-retry from ATP. We're now sending 12 >fast packets in 0.3 seconds and getting stomped for 2 seconds instead >of sending 40 per second. 12/2.3 : 40/1 is an 87% slowdown. Some? 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. 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. But let's grant your figures for the sake of argument. So what do you intend to do about it? You'll get pretty much the same result if anything is talking to a LaserWriter, because the LaserWriter is going to be stepping on packets. (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.) It doesn't matter all that much whether the Mac has FlashTalk or not. In any case, the obvious solution is to improve your timeouts; make them 0.5 seconds and post the measurements, s'il vous plait. >Let's say the packet that gets clobbered is an ATP TREL packet (the >ATP XO sequence is TREQ, TRSP, TREL). Between 10% and 30% of our packets >are TREL's (but they're shorter than the data packets - about 30 bytes). >For CAP, each TREL dropped incurs a 30 second stall - not a nice thing >to witness. With AppleShare, you have two listeners on the socket, so >you can drop ONE TREL per 30 second period without penalty. Or else >you get the difference. With this added, you're probably up to 90% to >95% performance degradation. Again, these timeout values are tuned badly. >Jerome's distributor knew what he was talking about. Not really. You'd have pretty much the same problems with any situation where FlashTalk-equipped Macs had to talk with LocalTalk-only devices, like LaserWriters and many network gateways and bridges. >Maybe the real advantage is that the physical cable can now handle THREE >times the volume of traffic. Like three times as many Macs performing >simultaneous data transfer before the net clogs up. Think of it as the >difference between a one-lane and a three-lane road. Not much >difference at 2:00am (when programmers go to work :-), but a lot of >difference to us ordinary folk during the rush hour. Kind of a strange thing to say right after complaining about the number of collisions. I hope those packets have air bags. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "A book is the product of a contract with the Devil that inverts the Faustian contract, he'd told Allie. Dr Faustus sacrificed eternity in return for two dozen years of power; the writer agrees to the ruination of his life, and gains (but only if he's lucky) maybe not eternity, but posterity, at least. Either way (this was Jumpy's point) it's the Devil who wins." -- Salman Rushdie, THE SATANIC VERSES
tom@wcc.oz (Tom Evans) (12/20/89)
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
psych@watserv1.waterloo.edu (R.Crispin - Psychology) (12/21/89)
We purchased Flashtalk boxes for our student network (10 machines) after experiencing success with only 2 stations equiped with them. Increaseing the number of equiped stations to 3 basically stopped the network altogether. We talked to the people at TOPS and have tried everything they suggested and nothing has worked. The fastest packet throughput is on the slow machines. We are (after 10 months of trying) giving up on them. They have been a waste of $1,800. I am hoping to be able to get some or all our money back. I wouldn't advise anyone to buy these. The DaynaTalk boxes at least do collision checking and may be better than FlashTalk. Richard Crispin Dept. of Psychology Bitnet: psych@watdcs University of Waterloo Unix : psych@watserve1.UWaterloo.ca Waterloo, Ont. Canada N2L 3G1 (519)885-1211 ext 2879
tim@hoptoad.uucp (Tim Maroney) (12/24/89)
In article <447@watserv1.waterloo.edu> psych@watserv1.waterloo.edu (R.Crispin - Psychology) writes: >We purchased Flashtalk boxes for our student network (10 machines) after >experiencing success with only 2 stations equiped with them. Increaseing >the number of equiped stations to 3 basically stopped the network altogether. >We talked to the people at TOPS and have tried everything they suggested >and nothing has worked. The fastest packet throughput is on the slow machines. Very weird. They have been tested with far more than ten machines. Have you checked to see if one of them is bad, or if the problems stop when a particular Mac is taken out of the network? Are you using any routers, bridges, gateways, concentrators, etc., that might be misbehaving with FlashTalk? >We are (after 10 months of trying) giving up on them. They have been a >waste of $1,800. I am hoping to be able to get some or all our money back. >I wouldn't advise anyone to buy these. The DaynaTalk boxes at least do >collision checking and may be better than FlashTalk. FlashTalk does do collision checking. It's Localtalk that can't tell if a higher-speed packet is already using the bus. I would imagine that DaynaTalk has the same problem; I don't see how a higher-speed packet can be detected by an unmodified Mac. Anyone have any solid information on this? I want to make it clear that I mostly agree with Richard's conclusion; from the start (that is, when the product was released and TOPS began their deceptive advertising campaign for it), I've been pointing out that the actual speed benefits are considerably less than a factor of three, and overall, are unlikely to be apparent to many users. The boxes are clearly overpriced for the benefits, and I don't recommend their purchase. When I seem to be defending them here, it's only because seemingly questionable statements are being made. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Something was badly amiss with the spiritual life of the planet, thought Gibreel Farishta. Too many demons inside people claiming to believe in God." -- Salman Rushdie, THE SATANIC VERSES