jamal wrote:
On Thu, 2005-03-03 at 18:48, Baruch Even wrote:
The queue is there to handle short bursts of packets when the network
stack cannot handle it. The bad behaviour was the throttling of the
queue,
Can you explain a little more? Why does the the throttling cause any
bad behavior thats any different from the queue being full? In both
cases, packets arriving during that transient will be dropped.
If you have 300 packets in the queue and the throttling kicks in you now
drop ALL packets until the queue is empty, this will normally take some
time, during all of this time you are dropping all the ACKs that are
coming in, you lose SACK information and potentially you leave no packet
in flight so that the next packet will be sent only due to retransmit
timer waking up, at which point your congestion control algorithm starts
from cwnd=1.
You can look at the report http://hamilton.ie/net/LinuxHighSpeed.pdf for
some graphs of the effects.
the smart schemes are not going to make it that much better if
the hardware/software can't keep up.
consider that this queue could be shared by as many as a few thousand
unrelated TCP flows - not just one. It is also used for packets being
forwarded. If you factor that the system has to react to protect itself
then these schemes may make sense. The best place to do it is really in
hardware, but the closer to the hardware as possible is the next besr
possible spot.
Actually the problem we had was with TCP end-system performance
problems, compared to them the router problem is more limited since it
only needs to do a lookup on a hash, tree or whatever and not a linked
list of several thousand packets.
I'd prefer avoiding an AFQ scheme in the incoming queue, if you do add
one, please make it configurable so I can disable it. The drop-tail
behaviour is good enough for me. Remember that an AFQ needs to drop
packets long before the queue is full so there will likely be more
losses involved.
Baruch
|