Re: Is bandwidth parameter wrong in current OpenBSD's ALTQ/HFSC?

["Alexey E. Suslikov" <cruel@texnika.com.ua>]

Monday, February 16, 2004, 3:54:59 PM, you wrote:

> 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%)

this is non-working:

bandwidth for Q1 invalid (0 / 0)
./pf.conf:xx: errors in queue definition

> but the following might be close to what you are trying to achieve:
>         queue Q1 hfsc (linkshare 10Kb, upperlimit 32Kb)

sorry, but why not linkshare 0%? i don't want to share bandwidth
available, just hard limit the queue!

but in case of linkshare 0% i have got

pfctl: link-sharing sc exceeds parent's sc
./test:xx: errors in queue definition

against

altq on fxp0 bandwidth 256Kb hfsc queue \
{Q1,Q2,Q3,Q4,Q5,Q0}
queue Q1 hfsc (upperlimit 32Kb linkshare 0%)
queue Q2 hfsc (upperlimit 32Kb linkshare 0%)
queue Q3 hfsc (upperlimit 32Kb linkshare 0%)
queue Q4 hfsc (upperlimit 32Kb linkshare 0%)
queue Q5 hfsc (upperlimit 32Kb linkshare 0%)
queue Q0 hfsc (upperlimit 32Kb linkshare 0% default)

> 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
> hfsc.
> (I agree that it's confusing for those who knows hfsc, though.)

not only confusing, it just don't want to work as expected :/
as for me bandwidth is bogus with hfsc...