If txqueuelen=2 or 4, shouldn't the link adapt somehow to ensure
that packets aren't dropped due to overflows of the outgoing
buffer?
TCP's slow-start and congestion avoidance adapt to this, but dropped
packets, and feedback induced from such events, are what puts the
gears in motion. So if it takes longer to get this feedback, it takes
longer for congestion avoidance to kick in and put the stream into
equilibrium.
In 2.0.x we had some horribly gross (yet effective) hacks in the
packet queueing layer that would go right into the devices queues and
take back + requeue packets if the device queue overflowed, then try
again later. It was gross, but it worked and solved most of these
serial link problems. It can't be done anymore, trust me when I say
that we are better off without that code existing any more :-)
If not, wouldn't it be better to keep txquueuelen high and
just grin and bear the latency for interactive use?
No you want it smaller, this makes packet loss feedback happen much
more quickly, and thus TCP's heuristics respond to the situation
faster.
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/