Ethernet Pause Frame functionality

Tod Hansmann at
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.

-Tod Hansmann

More information about the PLUG mailing list