[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is bandwidth parameter wrong in current OpenBSD's ALTQ/HFSC?
Alexey E. Suslikov wrote:
> in the first answer, Henning said:
> >> original altq hfsc class' implementation have no "bandwidth"
> >> parameter, but "pshare" ("linkshare" in current implementation)
> >> and "grate" ("realtime").
> >> so, if someone knows, which purpose of the hfsc class' "bandwidth"
> >> parameter in current implementation?
> > pfctl_altq.c, in eval_pfqueue_hfsc():
> > /* if link_share is not specified, use bandwidth */
> > if (opts->>lssc_m2 == 0)
> > opts->>lssc_m2 = pa->bandwidth;
> but if we assume the following declaration:
> #allocate guaranteed 32Kb and do not try to borrow
> queue Q1 bandwidth 32Kb hfsc (realtime 32Kb, linkshare 0%)
> linkshare==0% - we don't want to assing shared bandwidth to this
> queue. but the code shown above tells what if linkshare==0 altq
> will use bandwidth value as linkshare's m2 value.
> but this is not the same! even worst: we can't assing zero value
> to bandwidth parameter. this is equivalent to "have no ability
> to define non-borrowable queues": the minimum value for linkshare
> (or bandwidth) is 1%.
you can do the following:
queue Q1 bandwidth 0% hfsc (realtime 32Kb, linkshare 0%)
but the following might be close to what you are trying to achieve:
queue Q1 hfsc (linkshare 10Kb, upperlimit 32Kb)
the original hfsc from cmu didn't have these features as hfsc was
designed to be work-conserving.
altq extends hfsc and makes it non-work conserving when
zero-linksharing or upperlimits are specified.
> so the question is: "who needs two broken config parameters to
> control one variable"?
hfsc has 2 distinct bandwidth parameters; one for the realtime
scheduling and the other for the linksharing scheduling.
so, the bandwidth parameter is redundant but the current
implementation is less surprising for those who don't understand
(I agree that it's confusing for those who knows hfsc, though.)