Ignition (was Re: tftp config problem (ltsp))

Coleman Kane cokane at cokane.org
Mon Nov 12 10:26:21 EST 2007


Ben Scott wrote:
> On Nov 11, 2007 11:29 AM, Coleman Kane <cokane at cokane.org> wrote:
>   
>> Have you looked into the ethernet switch as the culprit, rather than the
>> cards / drivers themselves?
>>     
>
>   It's not a problem with the switch, the cards, the drivers, or
> anything by itself.  It's not an implementation defect at all.  It's a
> design limitation of how Ethernet works (or fails to, depending on
> your point-of-view).
>
>   You've got a server connected to the switch at 1000 Mbit/sec.
> You've got a client connected to the same switch at 100 Mbit/sec.  The
> server is sending data faster than the client can accept it.  The
> switch will buffer frames, in the hopes that the server will stop
> sending soon, and then the switch will be able to empty the buffer
> into the client at a slower rate.  If the server does not stop
> sending, eventually the switch runs out of buffer memory, and has to
> start dropping frames.  There's nothing else it can do.
>
>   Well, not exactly.  The switch could send an Ethernet flow control
> "pause" message to the server, asking it to stop transmitting.
> However, this is not as simple as it seems.  Ethernet flow control is
> all-or-nothing.  If the switch asks the server to stop sending, it
> stops sending *for everybody*, even if there are other clients which
> are not having problems keeping up.  So a single overwhelmed port
> would bottleneck the entire network.  Thus, most switches do not send
> pause requests unless the entire switch is overwhelmed.
>
>   And who knows if the server would even honor a pause request?
> Ethernet is a jungle of optional features and poorly-implemented
> standards.
>
>   Good write-up here:
>
> http://www.networkworld.com/netresources/0913flow2.html
>
>   Obviously, the ideal thing to do would be to use a data link
> protocol which actually works under adverse conditions, but the world
> went with Ethernet instead.
>
> -- Ben
>   
I suppose that answers my query. By "the switch as the culprit" I was
getting at the question of whether or not the switch was implementing
the appropriate flow control. Though, you point out that flow control is
a two-way street and the other end must obey it too, or else it is
useless...

So the solution is not to bog down the network switch with slower devices?

--
Coleman Kane



More information about the gnhlug-discuss mailing list