1Mbps of ARP traffic is insane... there must've been something really wrong with the ARP timers on that core router, amongst other issues.
I haven't had an in-depth Canopy discussion since Chuck (main Canopy software programmer) left Motorola, but I'm sure there is no 1mbps bit rate in Canopy - excluding the 900mhz products, the FSK bitrates are only 10mbps air (7mbps usable) and 2x which is double that. I think multicast frames may be in a special part of the AP downlink frames so it may be bandwidth-limited in that regards. The two-step speed means that minimum-speed multicast data doesn't cause a hugely detrimental effect like on wifi-based systems - it'll still go out at 7mbps. I think, based on these and other issues with wifi, calling Canopy and wifi similar is a stretch without grouping everything that sends ethernet frames over radio waves together. I can try to e-mail Chuck if we want an answer from the guy who made the system. Anyways, this'll never be even possibly a problem for Sksp. We'll never have enough hosts (200+) to cause more than a few tens of kbps of broadcast traffic - currently the router shows 4packets per second in+out (2kbps) for 40 hosts. And we can set the basic rate on the wifi APs to 54mbps if we want, too bad for the people with weak signals! On Sat, Dec 7, 2013 at 9:21 PM, Adam Thompson <athom...@athompso.net> wrote: > On 13-12-07 08:41 PM, Colin Stanners wrote: > >> I've seen networks with hundreds of switched hosts (not my design) only >> do ~100-200kbps of ARP broadcasts. The ARP traffic with the dozens of hosts >> on the Sksp network is probably less than the few kbps of wifi beacon >> frames sent out by the APs. If you really want we can route the APs, but >> I'd rather keep it simple. >> >> Unfortunately, my case was all public IPs, which meant inbound port > scans generated ARP traffic from the core router. We had about 1Mbps of > ARP traffic at times. > > That doesn't sound bad until you realize that WiFi (and Motorola Canopy, > which is sorta WiFi-like) will generally transmit broadcast and multicast > frames at 1Mbps to ensure that all the radio clients - no matter how crappy > their connection - receive the broadcast frame. (And, of course, there's > no such thing as multicast in RF. Or even unicast, technically...) > > To make accurate performance predictions, you have to stop thinking of > WiFi as being bandwidth-constrained; it's actually timeslot-constrained. > If you have one client running at 1Mbps, every Kbit it sends or receives > takes a 54Kbit chunk of "bandwidth" away from a better/faster client. If > you have ten clients at 1Mbps, assuming they're all fairly chatty, you only > have [warning: bad math ahead] at best 40Mbps left of your theoretical > 802.11g 54Mbit connection. (In practice, it's actually worse than that, > but luckily clients with crummy connections tend to not be terribly chatty.) > And, of course, every bcast/mcast packet the fast-talker sends actually > chews up ~10x the bandwidth a single packet would, because it gets > re-broadcast back out so the other clients can hear it! (Some APs mitigate > this and claim it's a "security" feature: Client Isolation.) > > Colin, I know my math is wrong, can you provide a cleaner estimate? (WiFi > and Canopy follow the same math.) > > -- > -Adam Thompson > athom...@athompso.net > Cell: +1 204 291-7950 > Fax: +1 204 489-6515 > > > _______________________________________________ > SkullSpace Discuss Mailing List > Help: http://www.skullspace.ca/wiki/index.php/Mailing_List#Discuss > Archive: https://groups.google.com/group/skullspace-discuss-archive/ >
_______________________________________________ SkullSpace Discuss Mailing List Help: http://www.skullspace.ca/wiki/index.php/Mailing_List#Discuss Archive: https://groups.google.com/group/skullspace-discuss-archive/
