Re: [NTLK] New Appletalk zone has zapped me

From: R Pickett (emerson_at_hayseed.net)
Date: Thu Nov 08 2001 - 15:55:32 EST


On Thu, 2001-11-08 at 05:52, Eric L. Strobel wrote:
> YES! That's my recollection. That's why I was wondering about the
> explanation that was given. If you're just using a few AppleTalk printers
> and maybe one AppleTalk file server, aren't those the only items doing
> broadcasts. But since I know nothing about the details of how networks work
> I accepted the explanations.

Yah, and my explanation kind of mumbled that part. AppleTalk devices
-that are providing services- do these broadcasts. See below, though.

> After thinking more on this, though, there were two things that I wondered
> about. First, just how big is this broadcast that each AppleTalk device
> sends? Second, I'm not clear on how OTHER protocols are less of a burden on
> bandwidth. After all, (going back to my example of the 20 MB file sent over
> the network to a spooler, only to be sent over the network AGAIN to the
> printer), regardless of where that file is addressed to, isn't that STILL
> just a bunch of packets on the wire, or on the hub/router? Isn't the
> difference simply on one hand a small amount of info sent everywhere versus
> huge chunks clogging the choke points?

In a network built totally of ethernet hubs, the world works that way --
everyone sees all the traffic, and the 20MB file chews up lots of the
bandwidth for everyone. The hub is just a 'dumb' repeater with roughly
zero logic.

Lets take my home office switched network as a counterexample. I have a
24-port switch, 24 ports of 10/100 Ethernet. These ports are connected
internally via a wide, fast bus with 1.2 GBps bandwidth. When that 20MB
file comes in on port 1 and out on port 2, even at 100MB/s, it's only
taking up 1/12 of the available backplane bandwidth. Ports 3-24 don't
see -any- news of this, and in fact, look, ports 3 and 4 are having a
-different- 20 MB file being sent between them, also not making the
switch break a sweat, and not disturbing any other ports. OK?

So. We plug in a Mac and power it up. It does an ethernet broadcast.
A broadcast is aimed at all Ethernet devices. The switch can't switch,
because there's no one destination. So, even if this is just a 100K
blat from the Mac (I have no actual idea how big it is; it's probably
variable based on all sorts of things), it gets shoved down all the
ports, and causes collisions. All of our 20MB file transfers that were
peacefully cruising along not aware of any other network activity have
to stop, back off, reframe, and pick back up where they left off. Over
and again for some number of tens of milliseconds until the Mac shuts
up, say 100K later.

Not a big deal until you have 50 of them doing this periodically,
chopping up your otherwise smooth switched stream. Things start to bog
when collisions occur, and collisions occur with broadcast. Sense?

> Just curious, but how is the estimate of 80-100 machines arrived at?
> That is, if it's something that permits a brief explanation.

Mostly just eyeballing it. Say your average file transfer takes 1/2
second, I'm imagining trouble when your number of Macs approaches your
broadcast time * 2 -- that is, there starts to be a chance that the
broadcasts are often enough to disturb your average file transfer.

Voodoo, smoke, and mirrors.

> I wonder if that's 5 seconds from opening Chooser. If the OS is
> keeping track of the broadcasts, then that doesn't have to necessarily
> mean broadcasts every five seconds.

The OS is probably keeping track of the broadcasts, but the broadcasters
don't know if someone else just came on line, so need to keep
advertising. There's also probably a 'timeout' so that the OS's
internal list of available resources expires stale entries, so the
Chooser doesn't show you someone that powered down several minutes ago.

On Thu, 2001-11-08 at 11:44, Lou Forlini wrote:
> True, but this would only be for machines acting as servers. If
> you have 80-100 machines all sharing files, it's probably time to
> rethink the setup :)

I won't get into my full rant here about the unmanageability of Macs in
largescale enterprise settings, but when you have 100 Macs on the floor,
you have 100 Macs sharing files. Everyone turns on file sharing real
quick just to let Jimbo get at that new graphic file, and don't turn it
off. And without a -steep- investment in third party management
software, that means somebody has to walk around to each of the Macs at
the end of the day and turn File Sharing back OFF, and then take the
brunt of the yelling when the users get snippy. (*shrug)

We're in the IP age now; it's mostly all moot.

> I'm sure you didn't. Sorry, I'm a little sensitive on this topic
> since a lot of places still use the "chatty" argument as a
> justification for not letting Macs onto a network. It becomes even
> more stupid when the Macs won't even be running AppleTalk, but TCP/IP.

That's more than stupid, that's just boneheaded. At the job I keep
alluding to with the 100 Macs on the floor, once MacOS file and print
sharing over IP got viable, we started rolling out Macs without the
AppleTalk stuff even on the machine. "Here. Use IP, be a good
citizen." Almost zero complaints from users or admins once we made that
change. (God, I'm almost crying with joy at remembering that week....)

Macs -can- play nice on a network, you just have to use a network
protocol that has some innate intelligence, and that's not AppleTalk.

OK, I think I'm done unless someone else wants to keep talking about
this. This has been sort of on-topic, but....

-- 
R Pickett           The people that once bestowed commands, consulships,
Hayseed Networks    legions, and all else, now meddles no more and longs
emerson_at_hayseed.net eagerly for just two things  --  bread and circuses.

-- This is the Newtontalk mailinglist - http://www.newtontalk.net To unsubscribe or manage: visit the above link or mailto:newtontalk-request_at_newtontalk.net?Subject=unsubscribe



This archive was generated by hypermail 2.1.2 : Sat Dec 01 2001 - 20:02:24 EST