On Thu, Mar 03, 2005 at 05:26:51PM -0500, jamal wrote:

On Thu, 2005-03-03 at 17:02, John Heffner wrote:

quoted

On Thu, 3 Mar 2005, Stephen Hemminger wrote:

quoted

Maybe a simple Random Exponential Drop (RED) would be more friendly.

That would probably not be appropriate.  This queue is only for absorbing
micro-scale bursts.  It should not hold any data in steady state like a
router queue can.  The receive window can handle the macro scale flow
control.

recall this is a queue that is potentially shared by many many flows
from potentially many many interfaces i.e it deals with many many
micro-scale bursts.
Clearly, the best approach is to have lots and lots of memmory and to
make that queue real huge so it can cope with all of them all the time.
We dont have that luxury - If you restrict the queue size, you will have
to drop packets... Which ones?
Probably simplest solution is to leave it as is right now and just
adjust the contraints based on your system memmory etc.

Why not have smaller queues but per interface? this would avoid
introducing too much latency and keep memory consumption low
but scale as we add more interfaces. It would also provide some
kind of fair queueing between the interfaces to avoid highspeed 
nics to starve lowspeed ones.

Queue length would still be an issue though, should somehow be 
related to interface rate and acceptable introduced latency.

Regarding RED and other more sophisticated algorithms, I assume
this is up to the ingress qdisc to take care of. What the queues
before the ingress qdiscs should do, is to avoid introducing
too much latency. In my opinion, low latency or high burst
tolerance should be the choice of the admin, like for egress.

I am not very familiar with the linux code, so I may be completly
wrong here...

Regards
-- 
        Programmer
        Edgar E Iglesias [off-list ref] 46.46.272.1946