Hi, On Mon, Nov 23, 2009 at 08:41:58AM -0500, Ross Vandegrift wrote: > The answer is very simple: if someone thinks that ethernet flow > control is the answer, the burden of proof is on them to answer > difficult questions about what the actual problem is, what flow > control is going to solve, and why they think that it won't cause more > problems than its worth. At best it does nothing, realistically it > interferes with TCP flow control, and at worst it pauses your storage > and breaks every client.
I tend to disagree with this statement in this broadness. We've seen
problems where lack of flow control combined with a switch with too-tiny
buffers and bursty ingress traffic led to buffer overflow on egress, and
packet loss. If the switch would use flow control here to space the
ingress traffic better (that is: stop and restart the flow for milliseconds
at a time), packet loss would be avoidable.
Of course, this can indeed fire backwards - as in: one egress port is
way overloaded, and flow control spreads the pain from there to all other
egress ports served by the ingress port in question.
So indeed, flow control is not a panacea. I agree with this :-)
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]
fax: +49-89-35655025 [email protected]
pgpYfX2yI3ftv.pgp
Description: PGP signature
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
