On Tue, Apr 24, 2007 at 09:49:32AM +0200, Federico Giannici wrote:
> jared r r spiegel wrote:
> >On Tue, Apr 24, 2007 at 01:42:26AM -0400, jared r r spiegel wrote:
> >>On Mon, Apr 23, 2007 at 10:12:56AM +0200, Federico Giannici wrote:
> >>
> >>>How can I make a single queue don't borrow ALL the traffic?
> >> upperlimit
>
> OK, my question was badly expressed.
> I have already written the problem a few times: the question is not to
> put an upper limit to a queue but to don't make it "monopolize" all the
> bandwidth because of its great amount of traffic, leaving queues with
> low traffic with ALL packets dropped (as you van see in the pftop
> snapshot I sent).
>
> I already explained it with the following example:
> Both users A and B have an assigned bandwidth of 1 bps.
> User A currently requires 4 bps.
> User B currently requires 100 bps.
> There are currently available 10 bps.
>
> I'd like that the 10 bps would be equally distributed to both users (as
> they have the same assigned bandwidth), so both had potentially 5 bps.
> User A uses 4 bps and leaves 1 bps to user B that so uses 6 bps.
>
> This is the "fair" bandwidth assignment I'd like to implement.
>
> Indeed it seems that, as user B requires 25 times more bandwidth of user
> A, then it is assigned almost ALL bandwidth, and user A is not able to
> use more then it's committed 1 bps, and so 3 out of 4 bits are dropped!
>
>
> > in this case it is probably not super important to see your
> > whole pf.conf, but without seeing the service curves you're
> > applying to the queues, it's a bit of flying blind.
> >
> > it seems to me that what you want to do is feasible with HFSC.
> >
> > posting your altq section would be helpful in trying to
> > resolve the problem you're seeing.
>
> Attached is the part of the pf.conf files that defines that part of
> queues. As you can see it's pretty simple. (Only wh1_i has an upperlimit
> because all the others have a limit in their router.)
how did wh10_i get to be 527KB/s if wdsl_i is capped out at 1650Kb/s?
> queue wdsl_i bandwidth 1650Kb { wdsl_hi_i wdsl_low_i }
> queue wdsl_hi_i bandwidth 99% { wh1_i wh2_i wh3_i wh4_i wh5_i wh6_i
> wh7_i wh8_i wh9_i wh10_i wh11_i wh12_i wh13_i wh14_i wh15_i wh16_i wh17_i
> wh18_i wh19_i wh20_i wh21_i wh22_i wh23_i wh24_i wh25_i wh26_i wh27_i wh28_i
> wh29_i wh30_i wh31_i wh32_i wh33_i wh34_i wh35_i wh36_i wh37_i wh38_i wh39_i
> wh40_i wh41_i wh42_i wh43_i }
> queue wh1_i bandwidth 6400b hfsc( linkshare 6400b
> upperlimit 2048Kb )
> queue wh2_i bandwidth 6400b hfsc( linkshare 6400b )
> queue wh3_i bandwidth 6400b hfsc( linkshare 6400b )
> queue wh4_i bandwidth 2000b hfsc( linkshare 2000b )
> queue wh5_i bandwidth 2000b hfsc( linkshare 2000b )
<snip>
i've never used HFSC without explicitly defining realtime <sc>s.
when i pass your queues through pfctl -nvvf after the following
edits:
- i took only the first 12 whX_i queues
- put in the missing 'altq on'
- added wdsl_low_i, and made it default
i see:
----
[/home/jrrs] $ pfctl -nvvf pf.test
altq on em0 hfsc bandwidth 8Mb tbrsize 6000 queue { wdsl_i }
queue wdsl_i bandwidth 1.65Mb { wdsl_hi_i wdsl_low_i }
queue wdsl_low_i bandwidth 1% hfsc( default )
queue wdsl_hi_i bandwidth 99% { wh1_i wh2_i wh3_i wh4_i wh5_i wh6_i wh7_i wh8_i
wh9_i wh10_i wh11_i wh12_i }
queue wh1_i bandwidth 6.40Kb hfsc( upperlimit 2.05Mb )
queue wh2_i bandwidth 6.40Kb
queue wh3_i bandwidth 6.40Kb
queue wh4_i bandwidth 2Kb
queue wh5_i bandwidth 2Kb
queue wh6_i bandwidth 2Kb
queue wh7_i bandwidth 2Kb
queue wh8_i bandwidth 2Kb
queue wh9_i bandwidth 2Kb
queue wh10_i bandwidth 6.40Kb
queue wh11_i bandwidth 6.40Kb
queue wh12_i bandwidth 2Kb
----
the first thing that strikes me is that there are no HFSC specific
declarations there for the subqueues, only 'bandwidth'.
in my experience with HFSC, the bandwidth keyword has very little to
do with anything other than it having to be set low enough so that
the sum of all the child queues' bandwidth doesn't exceed the parent.
i guess that the rest of the parameters are not present (in my pfctl output)
because the ones in the queue declarations in pf.conf equate to what
the defaults would be. changing the linkshare a bit seems to corroborate
this.
my first guesses would be to define a realtime explicitly (as 6400b for
one of your 6400b queues is certainly not the default, as it shows up
in pfctl -nvvf output if you explicltly say it) and/or to use an actual
<sc> for linkshare (define m1 and d) instead of a static number (which then
equates to having only defined m2).
from what i understand of HFSC, the service curves are where the real magic
happens -- if you're not using them in a curve fashion at all, it seems
that you end up with something not very different from regular CBQ.
it may also help, if the interface these queues hang off of has more
bandwidth (say, link of 100Mb?) than you're trying to limit
people to (in the popular case), to decrease your tbrsize, but i don't
mean to say i think the tbrsize is the primary cause of what you're seeing.
--
jared
