Ethernet Pause Frame functionality
plug.org at todandlorna.com
Fri Feb 3 20:44:49 MST 2012
I've broached this subject before, and since have become far more
educated on the effects of ethernet switching on the network. (We had
thought dead clients were sending out bad data on the wire. Not so.)
What we have is the same scenario as before:
Server -> 8 port "smart" Gig switch -> 5 x 24 port unmanaged gig
switches -> 100 clients (20 per switch)
The issue is, the clients sometime hang, and we're sending multicast UDP
traffic out from the server to all clients. It's not a multicast group
anyone has to join, since we're just switching between the two. So
really it behaves quite like broadcast traffic.
When the clients do hang, sometimes we get pause frames to the server.
Sometimes a few, and nothing is really problematic. Sometimes a lot,
and it really slows things down. The server can be configured to ignore
pause frames/flow control, and simply blast stuff out anyway. The
protocol we're using has it's own flow control, so we don't really want
pause frames, truth be told.
So my theory and thus the question is, if we just replaced the 8-port
switch with a switch that didn't have any 802.3x Ethernet Flow Control
support, would pause frames basically be ignored throughout the whole
system, and the server could blast out to any clients that could keep up
as fast as it wanted? Would a hung client be able to slow anything down
at the ethernet level? My own thinking says it would make Flow Control
useless and the client, so long as it's not sending data anywhere,
wouldn't be able to do anything to the rest of the network. I just need
to verify that thinking.
Mind you, 99% of the traffic is flowing one way from server to clients,
and its UDP. Clients send very, very little back to the server.
More information about the PLUG