[LARTC] 2.6.14 - HTB/SFQ QoS broken?

[Jody Shumaker]

Have you run a comparison when emule isn't running? As I mentioned before,
even with emule off you may not be capable of sending any faster to those
hosts.  Did you also try adjusting the burst rates?

Once again I stress that you do NOT need to over guarentee bandwidth. It
still makes absolutely no sense to me, and your thinking is flawed. It is
the rate guarenteed for that class, if you guarentee MORE bandwidth than
there is, then it gets really ugly for HTB figuring out how to divvy up the
bandwidth. Your goals are perfectly reachable by using correct guarenteed
rates, priorities, and ceilings. You have a complex way you want bandwidth
to be lended around, and you just need to set priorities and guarenteed
rates with that in mind. In fact, you might want to consider the exct
opposite setup. You should be thinking of guarenteed rate to be the rate you
want a class to get if every single class is trying to and capable of using
up to its ceil bandwidth.  Anything beond guarenteed rate you should be
thinking of adjusting prio and ceil. You should also consider that they
don't have to add up to the max rate, they just can't go over it.  It is
perfectly acceptable for the guarenteed rates to be below the max,  every
class will just have to borrow to get the full rate.

Also in your example you cited above, you didn't use one of the things I
suggested,  guarenteeing practically no bandwidth for emule. You actually
had it on par with apache and greater than skype or ftp. Why give it such a
high guarentee? That doens't fit at all with what you stated your target
result as.

I think the problem is likely either the transfers not capable of the full
bandwidth regardless, or possibly something that can be adjusted by using
the burst values as I mentioned. The defaults of ~1719b seem really poor for
a lower priority fewer connections class to reclaim its bandwidth. However,
testing any of this with incorrect guarenteed rates makes no sense to me.
Just because it worked in the past doesn't mean its the correct thing to do.
The fact it isn't working now certainly is not evidence that you want to use
settings in a way where the result is undefined.

So please understand that overlapping is not neccasary for your perfect
scheduler, please focus on what "guarenteed" rate means. Please actually try
my suggestions.  Even try them in both cases of incorrect rates, and correct
rates.  Over guarenteeing I still don't think is the best way to do things,
but heck if with the burst settings or some such you can get it working how
you want with over guarenteeing, then why mess with what works? I just want
you to understand, it should not be neccasary.

Also, I want to point out that with the tc statistics you last emailed,
you're shaping 384kbit, fairly close to the 512kbit I'm shaping. I'm getting
the exact results you want, so you might want to take a look at my class
setup. If even with a fairly identical setup you don't get results, I wonder
if its possibly a bug with your exact version of the kernel.

- Jody


On 12/28/05, Leo Bogert <spam-goes-to-dev-null at gmx.net> wrote:
>
> > Thus, some kind of overlapping might be necessary for a perfect
> > scheduler.
> >
> > I hope it is possible to understand what I was aiming for now.
> >
> > Thanks, Leo Bogert
>
> ...Besides, let me stress again that even though I would prefer
> overlapping guranteed rates, the default usage of HTB with
> sum of child rates = parent rate just seems BROKEN for me
> as it does no scheduling at all, the logs in one of my last
> mail show that HTB completely ignores the bandwidth
> reservations. That problem is what I need a solution for :)
>
> _______________________________________________
> LARTC mailing list
> LARTC at mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ds9a.nl/pipermail/lartc/attachments/20051228/9a989784/attachment.html