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

[Ben Scott]

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