Scalability of ALTQ

[Bernhard Schmidt]

On 2005-01-12, Bernhard Schmidt <berni at birkenwald.de> wrote:

>> From a very first glance, I think HSFC is what best suits your application.
>> Here again, you must make sure not to overload your parent with the
>> client bandwidth.
> Hrm, I guess I'll just convert a current Packeteer policy to an pf one
> and have a look whether it loads smoothly. I heard today that we already
> have a Dell PE750 on stock, I think I'll give it a shot. In the end,
> a mirrored switchport to the BSD box should be sufficient to test.

And me again ... I'm now having a problem where I'm not entirely sure
whether I misunderstood the manpage or there is a bug in the parsing.

I fell about some errors converting a small subset of our packeteer
rules to pf. I created a testcase with the following config

altq on vr1 hfsc bandwidth 5000001b queue { 1, 9999 }
queue 1 hfsc(red, realtime 5000000b, upperlimit 5000000b) { 2 }
queue 2 hfsc(red, realtime 4900000b, upperlimit 5000000b) { 3 }
queue 3 hfsc(red, realtime 4800000b, upperlimit 5000000b) { 4 }
queue 4 hfsc(red, realtime 4700000b, upperlimit 5000000b)

queue 9999 hfsc(default, red, realtime 0b, upperlimit 5000000b)

when loading I get

pfctl: real-time sc exceeds the interface bandwidth
pf.conf:3: errors in queue definition

apparently when using subqueues pf adds up the realtime bandwidth of all
queues and compares it to the interface bandwidth. To my understanding
the sum of the bandwidth of all child queues should be compared to the
direct parent queue. Am I wrong here?

Of course I could increase the bandwidth parameter on vr1 to something
really hillariously high, but is this the thing intended?

Bernhard