On 2/22/06, Christopher McGee <[EMAIL PROTECTED]> wrote:
> I might be going about this the wrong way, but, this is ultimately what
> I'm trying to do. One queue has guaranteed 3Mb, another has a
> guaranteed 4Mb, another has 3Mb guarantee, which leaves about 90Mb as a
> pool for all of them. If they are backlogged, I want the first 2 queues
> to be able to utilize the entire 90Mb, and the 3rd queue should be able
> to utilize about 25Mb of it. This is a simplified example of what I
> sent earlier. But if I can do this, I can accomplish what I'm trying to
> and build off it later.
If you're guaranteeing bandwidth allocation, then you want realtime,
and probably avoid the bandwidth declarations which are not quite the
same. HFSC is not trivial to get your head wrapped around and is
poorly documented because of that. It took me reading the man pages
and the PF guide several times over a couple months to get it
together.
Another example for you to peruse:
queue q_dmz hfsc(ecn realtime 50Mb upperlimit 90Mb) \
{ q_dmz_h, q_dmz_hb, q_dmz_l, q_dmz_lb }
queue q_dmz_h hfsc(realtime 10% upperlimit 90%) priority 7
queue q_dmz_hb hfsc(realtime 20% upperlimit 90%) priority 4
queue q_dmz_l hfsc(realtime 5% upperlimit 90%) priority 3
queue q_dmz_lb hfsc(realtime 10% upperlimit 90%) priority 0
Leave out the linkshare and bandwidth, just use realtime and
upperlimit. And the priority of the queues matters, in the above each
of the queues can go as high as 81Mb (90% of 90Mb) but if more than
one tries to go above 45Mb, the one with the higher priority gets
first chance at available bandwidth. Linkshare is another override; in
the above it is easily possible that the q_dmz_lb queue will get quite
backlogged as it gets last chance, adding linkshare would allow it to
bypass the priorities of the other queues. You may not want to even
use priorities, using just realtime and upperlimit is probably a lot
easier for your simplified example.
Using the service curves is even more complex. This is all based on my
experience and research, so it may not be correct, but it's the
explanation that I use.
--
Jon Simola
Systems Administrator
ABC Communications
_______________________________________________
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
