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@xxxxxxx> 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@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
_______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
