Ethernet Pause Frame functionality

Tod Hansmann plug.org at todandlorna.com
Sat Feb 4 08:44:11 MST 2012


On 2/3/2012 11:00 PM, Andy Bradford wrote:
> Thus said Tod Hansmann on Fri, 03 Feb 2012 22:18:47 MST:
>
>> It's a Netgear GS108t-200NAS, if I recall correctly (I'm not currently
>> at the office). I'm actually not too worried about the flooding of the
>> switch, as  we're only sending 8  MB/s max from the  server. Sometimes
>> far less (3  MB/s) and we get  pause frames not based  on the server's
>> state, but the clients' states.
> It might only  be 8MB/s, but what  is the size of your  packets? If they
> are 512 byte UDP datagrams, then that's between 6,144 and 16,384 packets
> per second.  Are you sure  that Netgear can  handle that? If  the packet
> size is even  smaller, then increase the  PPS and ask again.  How big is
> the buffer for forwarding packets on the switch? The specs don't seem to
> give these details, but I'm not  surprised about that for a $100 switch.
> What about  the rest  of the infrastructure?  I've never  been impressed
> with  Netgear.  They're  cheap  and poor  performers.  I  wouldn't  even
> recommend them in a home, and definitely not in a business.
>
> But,  it's also  interesting your  point about  the clients  sending the
> pause frames. Are they not able to handle the packets? If a client sends
> pause frames, that could possibly impact all clients, because there is
> only one  server, and ethernet frames  will slow for *all*  clients, not
> just the one that sent it, if I'm not mistaken.
>
Mmmm, you bring up some interesting pieces of info.  Two points.  The 
size of the packets is about 1400 bytes, but never varies enough to push 
it to two frames being needed.  I can't remember the exact number of 
bytes off the top of my head, but it has been brought up as a possibility.

Pause frames may or may not be originating from the clients.  We 
wouldn't know, because when pause frames start occurring at the server, 
the client is always in a state that we can't check it.  It's hung or 
unconnectable at the very least.  However, pause frames are only valid 
on the link, so they never get propagated through the switch.  The 
server is seeing pause frames from the distributions switch.  The 
switches could be sending pause frames to each other, and clients could 
be sending pause frames to their switches.  We don't know, and finding 
out would be interesting, but incredibly difficult and expensive to setup.

We actually don't mind if packets get dropped.  The scenario I described 
was to sanity check the idea of using an even dumber switch as the 
distribution switch that doesn't support pause frames to eliminate them 
from the entirety of the LAN.  If we are going too fast, we can account 
for that and slow down.

A nice article on some scenarios where Ethernet flow control causes 
headaches you don't want (like mine) is here for those interested: 
http://virtualthreads.blogspot.com/2006/02/beware-ethernet-flow-control.html

Cheers,

-Tod Hansmann


More information about the PLUG mailing list