[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[altq 196] Re: Overcommitting Classes...
Kenjiro Cho wrote:
> > Is there anyway we can get round this? - Perhaps by 'prioritising' the queues?
> > - Maybe then we can have the 'default' class at a higher priority than the
> > other classes, so they only get their share of the bandwidth _after_ the
> > default class has been processed...
> > Or is there a way of giving children classes 'up' to their maximum kbs,
> > without reserving the bandwidth out of the root class?
> I don't understand what you are trying to achieve by overcommitting
> bandwidth. Could you elaborate on it?
> >From the implementation's point of view, it is easy to add a flag to
> allow bandwidth overcommit. But I haven't been convinced of its
We want to be able to set the _maximum_ kbs for each class, to say 128kbs.
Assuming we have 512kbs, and 8 x 128kbs classes defined (i.e. potential
As the classes get busier, an individual class will not be able to go over
128kbs (which is good). What we want to be able to do is run with the 1024kbs
overcomitted, because we know that it's very rare for all 8 classes to become
'busy' at the same time.
The preferable behaviour would be to have the 8 classes continue to get busy,
until theres no more bandwith left, then for them to all 'settle' out with a
'fair' 64kbs each (or to prioritise between the classes - which I beleive we
can do at present)...
This isn't a real life example - we wouldn't overcommit usually by x2,
previously this is what seemed to happen with AltQ (i.e. the overcommit was
only a warning... In reality, we never had a situation whereby the classes all
got busy at the same time (e.g. some were high input classes, others were high
output classes, or had different time vs. traffic patterns).
If we do start hitting limits on classes (or the root bandwidth allocation),
we have the stats and graphs to warn us, and we can then bring the total
bandwidth up to accomodate the new peak demands.
Does this make any sense? :-)