Re: HTB: far unequal behaivor at a slight conf rate change [Solved]

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



El Friday 24 February 2006 06:36, Andreas Klauer escribió:
> On Thu, Feb 23, 2006 at 11:42:16PM -0300, Luciano Ruete wrote:
> > with vde_switch daemon listening in a tuntap device.
> > I suppose that htb is device independet, i hope it does not matter.
>
> I don't have any experience with vde_switch and tuntap's (I don't even know
> what those are, so much for ignorance). The only device-dependent factor I
> came across with HTB so far is the overhead problem - not all devices have
> the same overhead (PPP over Ethernet or whatever). So HTB calculating the
> rate incorrectly is a possibility. It can be tuned using overhead/mpu
> parameters, however in order to do that, you'd need to know correct values
> first, and they can be a little hard to come by. I also doubt it's the
> cause of your problem in this case.

you're rigth, and will not be the only time in this mail :-) 

> > class htb 1:7005 parent 1:7000 leaf 7005: prio 3 quantum 1500 rate
> > 23000bit ceil 230000bit burst 12Kb/8 mpu 0b overhead 0b cburst 1714b/8
> > mpu 0b overhead 0b level 0 class htb 1:7004 parent 1:7000 leaf 7004: prio
> > 1 quantum 1500 rate 207000bit ceil 230000bit burst 12Kb/8 mpu 0b overhead
> > 0b cburst 1714b/8 mpu 0b overhead 0b level 0 class htb 1:7000 root rate
> > 256000bit ceil 256000bit burst 12Kb/8 mpu 0b overhead 0b cburst 1728b/8
> > mpu 0b overhead 0b level 7
>
> The problem with this tree is that you took out the client class (the one
> with rate and ceil 230000bit). When I said that child classes without
> siblings don't make sense, I didn't mean to actually take out the child
> class, but rather take out the parent of this child class; in your example
> that would mean making the 230000bit class the root class.
>
> In your setup now, by just looking at the class tree, not the statistics,
> my guess would be that while each leaf class has a ceil of 230000bit,
> they won't share the same 230000kbit, but rather utilize the full 256kbit
> of their parent. That does not seem to be what you want. It still does
> not explain the rates in this setup, too.

yes, once again you're rigth, but i consider it irrelevant for the test that i 
was doing. Anyway, as you say, it still does not explain the situation... 

> Especially the rate of the parent class seems low - if this is a testing
> environment where you are filling out the classes to their maximum, it's
> really odd that the parent class does not use it's full bandwidth. On the
> other hand, I don't know how accurate the rate statistics of HTB are.
> I don't have access to a properly working shaping setup right now to
> verify wether it's the same on my setup.
>
> If it isn't, I'd probably check first how much rate HTB can actually
> use, because it's a very bad situation for HTB when it thinks it can
> use more bandwidth than the link actually can guarantee.

For the third time you are so rigth, i boot a second virtual machine, and test 
the same htb setup betwen the two virtual machins and using my gentoo as 
firewall. Obviously the bandwhidth between them can be considered infinite, 
and the setup works properly. So i made severals test to the link whit i was 
testing before and at any moment i get real 256kbit/s. This expains all the 
situation. Shame on me!!! 

I've added a FAQ about this to my project after this.
When i have a first public release(wich will be son), i will post here(if does 
not bother) for one time only the project url, and some words of what it 
does. For now i leave a stable snaphost of my git tree at 
git-clone http://www.lugmen.org.ar/~luciano/git-repo/htb-gen/.git
or simply point a browser to
http://www.lugmen.org.ar/~luciano/git-repo/htb-gen/

Many tanks for your help!

-- 
Luciano
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux