Date: Sat, 8 Jan 2005 00:27:23 +0000 (UTC) From: Bernhard Schmidt <berni@birkenwald.de> To: freebsd-pf@freebsd.org Subject: Re: Scalability of ALTQ Message-ID: <slrnctua7b.bfm.berni@bschmidt.msgid.cybernet-ag.net> References: <slrnctu80f.aet.berni@bschmidt.msgid.cybernet-ag.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Heya,
oh well, why do I always think of more questions the second I send my
message ....
At this point ...
> queue cust1 on fxp0 bandwidth 5Mb cbq { cust1_commit }
> queue cust1_commit on fxp0 bandwidth priority 2 10Mb cbq(borrow) { cust1_sub1, cust1_sub2 }
> queue cust1_sub1 on fxp0 bandwidth 10Mb cbq { cust1_sub1_commit }
> queue cust1_sub1_commit on fxp0 priority 2 bandwidth 2Mb cbq(borrow)
> queue cust1_sub2 on fxp0 bandwidth 0Mb cbq { cust1_sub2_commit }
> queue cust1_sub2_commit on fxp0 priority 2 bandwidth 10Mb cbq(borrow)
I made the error specifying the burstable margin for the "burst" queue
instead of the whole bandwidth. So pfctl would have kicked me for this.
So it should of course be
queue cust1 on fxp0 bandwidth 15Mb cbq { cust1_commit }
queue cust1_commit on fxp0 bandwidth priority 2 10Mb cbq(borrow) \
{ cust1_sub1, cust1_sub2 }
queue cust1_sub1 on fxp0 bandwidth 12Mb cbq { cust1_sub1_commit }
queue cust1_sub1 on fxp0 bandwidth 2Mb cbq(borrow)
which would kill me, too, since the sum of the child bandwidths (the
burstables) might very well be larger than the parent's bandwidth. So
I guess cbq is a dead end here.
Another thing quite interesting for me would be the queueing inside a
queue. Is it just FIFO or is there a way to allow fair bandwidth
distribution even with misbehaving sessions in it (think of a 50Mbps UDP
DOS which would probably kill all other communications in a queue).
Thanks again
Bernhard
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?slrnctua7b.bfm.berni>