Date: Wed, 22 Feb 2006 17:00:07 -0500 From: Christopher McGee <chris@xecu.net> To: Jon Simola <jon@abccomm.com> Cc: freebsd-pf@freebsd.org Subject: Re: Hfsc configuration problems Message-ID: <43FCDEE7.2010802@xecu.net> In-Reply-To: <8eea04080602221157h18555b9bxc2719b5a12f7362a@mail.gmail.com> References: <43FC9F63.5070009@xecu.net> <8eea04080602220957v46f9d11ev2544e8cbe893365d@mail.gmail.com> <43FCA7B8.3090300@xecu.net> <55e8a96c0602221042re25f819g1e3815384c022590@mail.gmail.com> <43FCB645.5000508@xecu.net> <8eea04080602221157h18555b9bxc2719b5a12f7362a@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jon Simola wrote:
>On 2/22/06, Christopher McGee <chris@xecu.net> 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
>
>
This information is very helpful. Here is my modified configuration,
unfortunately it still gets the same errors:
altq on $ext_if bandwidth 100Mb hfsc queue { high_pri, med_pri, junk }
queue high_pri hfsc(realtime 128Kb upperlimit 500Kb red) priority 7
queue med_pri hfsc(realtime 5Mb upperlimit 99% default ecn red) priority 5
queue junk hfsc(upperlimit 95% red)
Just to clarify what I'm trying to do... I'm trying to guarantee 128K
for high_pri stuff(ssh, carp, etc..) and allow up to 500Kfor it. Other
services, like web traffic etc.. falls in med_pri, which gets 5Mb all
the time but can use up to 99Mb. All other traffic, like cvsup, ftp,
etc... will get no guarantees, but can use up to 95Mb if it's
available. From all my reading, this seems correct but I still get the
parent sc errors.
Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43FCDEE7.2010802>