Understanding queue size

[Michael Sierchio]

jeremie le-hen wrote:

> I hadn't understood I had to play with queue size for each queues, and not
> with the one of the main pipe. But that's the key ! :)
> 
> Does reducing or increasing queue size of the main pipe have any relevance ?

You should have pipes for incoming and outgoing traffic that are
large enough (in terms of bw) for the burst/connect rate of your
connection.

Other than that, you may assign multiple queues to that pipe, and
bandwidth will be allocated fairly among them based on their weights.

> Finally, I should reduce size of interactive traffic queues, and increase
> size of the others. But how much ?

I'm not sure that this is really what you want to do...  interactive
latency starts getting to be perceptible at 0.125s and annoying at
0.5s,  but this depends on MTU size and other things as well.

One way of preventing a nearby or high-powered host from hogging
all the bandwidth (that power user with the dual 2.8GHz desktop
machine who's downloading mp3s all day) is to use RED or GRED.
Do some reading on it before asking how to set the parameters,
it's not an exact science.

That being said, make the queue size the equivalent to the tolerable
delay for interactive processes.

You might consider using masks on the interactive queues, since
interactive sessions can easily become bulk data transfer sessions
(an ssh tunnel).

And rememember: il faut garder quelques sourires pour se moquer
des jours sans joie.