Ethernet Pause Frame functionality
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:
More information about the PLUG