On Fri, Dec 2, 2011 at 12:14 PM, Lamar Owen lowen@pari.edu wrote:
My point is that every device on your network has to process every broadcast packet. Maybe you have CPU overkill on all your computers, but you might also have some dumb controllers too. And they have to go out the wifi too.
Ethernet multicast frames, depending on switch implementation, may go to every device as well. How the NIC responds to multicast ethernet frames is likely implementation-dependent, but, again, I don't have metrics on that, except for a failure mode on a couple of controller-type devices we experienced once.
NICs have to accept broadcasts and pass them up to CPU-type processes. They may have efficient mechanisms to ignore multicasts they aren't interested in (but yes, it is implementation - dependent).
This was not broadcast traffic; it was multicast traffic, but the switches flooded those frames to every port in that VLAN anyway, and a controller that was not a member of that multicast group got flooded. Now, to be fair, the SitePlayer Telnet does Bonjour, and thus does respond to mDNS, but that is supposed to be on a different multicast group. Whether that was a factor or not I don't know; but I do know that the Davis Instruments ethernet devices we have, and that don't do mDNS, also went offline during the multicast event.
So, no numerical metrics, but anecdotal evidence that multicast can be just as bad as broadcast to controllers with insufficient bandwidth or CPU power.
Yes, if you fill the media capacity, things start to break, and on a point-to-point connection like 10BT there's not much difference between the media and the endpoints.
(And it pointed to the fact that those SitePlayer Telnet boxes really should have been on a different VLAN and thus in a different broadcast domain.......)
You might still flood the VLAN trunked connections between switches where the media is shared - but in practice that would probably be a higher capacity.