[LARTC] Problem with HTB and ceil

[LARTC] Problem with HTB and ceil

[nik39_nospam]

Hi,

I am trying to setup a shaper for my linux box and I am experiencing some
problems. What I am trying to do is priorizing packets on the egress link,
therefore I have setup some prio classes etc. The priorizing seem to work but
the problem is that the ceil parameter doesnt seem to work on non leafs.
This is what stats show:

> class htb 1:1 root rate 3000bit ceil 3000bit burst 1602b/8 mpu 0b overhead 0b
cburst 1602b/8 mpu 0b overhead 0b level 7
> Sent 770965 bytes 2139 pkts (dropped 0, overlimits 0)
> rate 178264bit 62pps
> lended: 0 borrowed: 0 giants: 0
> tokens: -59999999 ctokens: -59999999

How can this be possible? From my understanding it shouldnt be possible to
exceed the ceil bitrate, but this happens here. What did I overlook?
What do these negative token counters mean?

Thanks for your help in advance.

nik

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

Re: [LARTC] Problem with HTB and ceil

[richard lucassen]

On Tue, 19 Jul 2005 07:52:03 +0200
nik39_nospam@usenet.entertain-men.de wrote:

> I am trying to setup a shaper for my linux box and I am experiencing
> some problems. What I am trying to do is priorizing packets on the
> egress link, therefore I have setup some prio classes etc. The
> priorizing seem to work but the problem is that the ceil parameter
> doesnt seem to work on non leafs. This is what stats show:
> 
> > class htb 1:1 root rate 3000bit ceil 3000bit burst 1602b/8 mpu 0b

3000bit

you probably mean 3000kbit?

R.

-- 
___________________________________________________________________
It's so simple to be wise. Just think of something stupid to say
and say the opposite.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht                                        |
| Public key and email address:                                    |
| http://www.lucassen.org/mail-pubkey.html                         |
+------------------------------------------------------------------+
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Problem with HTB and ceil

[nik39_nospam]

Zitat von richard lucassen <mailinglists@lucassen.org>:


> > I am trying to setup a shaper for my linux box and I am experiencing
> > some problems. What I am trying to do is priorizing packets on the
> > egress link, therefore I have setup some prio classes etc. The
> > priorizing seem to work but the problem is that the ceil parameter
> > doesnt seem to work on non leafs. This is what stats show:
> >
> > > class htb 1:1 root rate 3000bit ceil 3000bit burst 1602b/8 mpu 0b
>
> 3000bit
>
> you probably mean 3000kbit?

No, for debugging purposes I have limit it to 3kbps, to test what is going on.

nik




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

Re: [LARTC] Problem with HTB and ceil

[Carl-Daniel Hailfinger]

Hi,

nik39_nospam@usenet.entertain-men.de schrieb:
> 
> the problem is that the ceil parameter doesnt seem to work on non leafs.

IIRC that is by design. Some time ago, it was explained on this list
in a much better way than I could do it now.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Problem with HTB and ceil

[nik39_nospam]

Carl-Daniel Hailfinger <c-d.hailfinger.devel.2005@gmx.net>:

> > the problem is that the ceil parameter doesnt seem to work on non leafs.
>
> IIRC that is by design. Some time ago, it was explained on this list
> in a much better way than I could do it now.

Yes, thanks I found something but I am not sure how to interpret what has been
said. It has been said that if the child classes summed up exceed the bitrate
of the parent class then the parent ceil setting will be ignored. Now I am not
sure if that only applies to the sum of the minimum bitrate or also of the
summed ceil bitrates of all child classes. Let me explain what I am trying to
achieve:

I have a link with 384kbps upstream, I want voip traffic to have the highest
prio, they should always leave the upstream first with a ceil limit of 96kbps
which is more than enogh, min 16kbit (should matter cause its priorized
anyway). Next priority should be ACK packets, they should have a ceil limit of
(380-16) 364kbit, default bitrate of 140. This should ensure that downloads are
not affected by any outgoing traffic except the voip traffic. SSH traffic is
next, I reserved a minimum bitrate of 16kbit with a ceiling of 364, then I got
http traffic again with min bitrate 16kbit, ceil limit of 364 and at last bulk
traffic, with a min bitrate 16kbit and ceil limit of 364:

                  o root 1:0
                  |
  ________________+ 1:002
 /                |
 |                | 1:101
 |      __________+__________
 |      |      |      |      |
 |      |      |      |      |
 |      |      |      |      |
voip   ACK    SSH    http   bulk
pr 0   pr 1   pr 2   pr 3   pr 4
1:100  1:200  1:300  1:300  1:400


What I have achieved so far is that voip is really priorized agains all other
classes. But priorizing the right half does not work, means ACK class has not
higher prio than the others.

My config so far:

--------
## Root
/sbin/tc qdisc add dev $EXTIF root handle 1:0 htb default 400
/sbin/tc class add dev $EXTIF parent 1:0 classid 1:002 htb rate 380kbit ceil
380kbit

## voip
/sbin/tc class add dev $EXTIF parent 1:002 classid 1:100 htb rate 16kbit ceil
96kbit prio 0
## non voip
/sbin/tc class add dev $EXTIF parent 1:002 classid 1:101 htb rate 364kbit ceil
364 prio 1

## ACK
/sbin/tc class add dev $EXTIF parent 1:101 classid 1:200 htb rate 140kbit ceil
364kbit prio 1
## SSH
/sbin/tc class add dev $EXTIF parent 1:101 classid 1:300 htb rate 140kbit ceil
364kbit prio 2
## http/https traffic
/sbin/tc class add dev $EXTIF parent 1:101 classid 1:400 htb rate 140kbit ceil
364kbit prio 3
## bulk
/sbin/tc class add dev $EXTIF parent 1:101 classid 1:500 htb rate 140kbit ceil
364kbit prio 4
--------

Stats show:
--------
class htb 1:200 parent 1:101 leaf 200: prio 1 quantum 1750 rate 140000bit ceil
364000bit burst 1774b/8 mpu 0b overhead 0b cburst 2066b/8 mpu 0b overhead 0b
level 0
 Sent 280764 bytes 4995 pkts (dropped 0, overlimits 0)
 lended: 4995 borrowed: 0 giants: 0
 tokens: 79347 ctokens: 34819

class htb 1:500 parent 1:101 leaf 500: prio 6 quantum 1000 rate 16000bit ceil
364000bit burst 1619b/8 mpu 0b overhead 0b cburst 2066b/8 mpu 0b overhead 0b
level 0
 Sent 3351886 bytes 3165 pkts (dropped 0, overlimits 0)
 rate 256bit
 lended: 150 borrowed: 3015 giants: 0
 tokens: 237570 ctokens: 17997
--------

As you can see the :200 class (ACK packets) have much lower bitrate than the
:500 (bulk packets), which slows down my downloads.

Any hints?

nik

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

Re: [LARTC] Problem with HTB and ceil

[Andreas Klauer]

On Tuesday 19 July 2005 12:54, nik39_nospam@usenet.entertain-men.de wrote:
> /sbin/tc class add dev $EXTIF parent 1:002 classid 1:101 htb rate
> 364kbit ceil 364 prio 1
>
> ## ACK
> /sbin/tc class add dev $EXTIF parent 1:101 classid 1:200 htb rate
> 140kbit ceil 364kbit prio 1
> ## SSH
> /sbin/tc class add dev $EXTIF parent 1:101 classid 1:300 htb rate
> 140kbit ceil 364kbit prio 2
> ## http/https traffic
> /sbin/tc class add dev $EXTIF parent 1:101 classid 1:400 htb rate
> 140kbit ceil 364kbit prio 3
> ## bulk
> /sbin/tc class add dev $EXTIF parent 1:101 classid 1:500 htb rate
> 140kbit ceil 364kbit prio 4

By looking at this script, you have a class 1:101 with 364kbit rate, 364 
ceil (missing unit!), and it's children got (140+140+140+140)kbit = 
560kbit rate.

I haven't followed the prior discussion, so this might be intentional or 
not, but in any case, I don't recommend using HTB that way. It's much 
easier to tell what is happening when you make sure that your rates always 
add up properly. That is, the sum of the child class rates should be the 
same as the parent class rate.

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

Re: [LARTC] Problem with HTB and ceil

[nik39_nospam]

Andreas Klauer <Andreas.Klauer@metamorpher.de>:

> On Tuesday 19 July 2005 12:54, nik39_nospam@usenet.entertain-men.de wrote:
> > /sbin/tc class add dev $EXTIF parent 1:002 classid 1:101 htb rate
> > 364kbit ceil 364 prio 1
> >
> > ## ACK
> > /sbin/tc class add dev $EXTIF parent 1:101 classid 1:200 htb rate
> > 140kbit ceil 364kbit prio 1
> > ## SSH
> > /sbin/tc class add dev $EXTIF parent 1:101 classid 1:300 htb rate
> > 140kbit ceil 364kbit prio 2
> > ## http/https traffic
> > /sbin/tc class add dev $EXTIF parent 1:101 classid 1:400 htb rate
> > 140kbit ceil 364kbit prio 3
> > ## bulk
> > /sbin/tc class add dev $EXTIF parent 1:101 classid 1:500 htb rate
> > 140kbit ceil 364kbit prio 4
>
> By looking at this script, you have a class 1:101 with 364kbit rate, 364
> ceil (missing unit!), and it's children got (140+140+140+140)kbit > 560kbit rate.
>
> I haven't followed the prior discussion, so this might be intentional or
> not, but in any case, I don't recommend using HTB that way. It's much
> easier to tell what is happening when you make sure that your rates always
> add up properly.

Just to make sure, when you talk about the sum you are talking about the sum of
the minimum bitrates, not the sum of the ceil bitrates, right?

> That is, the sum of the child class rates should be the
> same as the parent class rate.

Ah damned, that was a copy and paste problem, in fact I used the following
script with the bitrates which I mentioned in the previous posts in my
description.

--------
## Root
/sbin/tc qdisc add dev $EXTIF root handle 1:0 htb default 400
/sbin/tc class add dev $EXTIF parent 1:0 classid 1:002 htb rate 380kbit ceil
380kbit

## voip
/sbin/tc class add dev $EXTIF parent 1:002 classid 1:100 htb rate 16kbit ceil
96kbit prio 0
## non voip
/sbin/tc class add dev $EXTIF parent 1:002 classid 1:101 htb rate 364kbit ceil
364 prio 1

## ACK
/sbin/tc class add dev $EXTIF parent 1:101 classid 1:200 htb rate 140kbit ceil
364kbit prio 1
## SSH
/sbin/tc class add dev $EXTIF parent 1:101 classid 1:300 htb rate 16kbit ceil
364kbit prio 2
## http/https traffic
/sbin/tc class add dev $EXTIF parent 1:101 classid 1:400 htb rate 16kbit ceil
364kbit prio 3
## bulk
/sbin/tc class add dev $EXTIF parent 1:101 classid 1:500 htb rate 16kbit ceil
364kbit prio 4
--------

Any idea? Did I miss something basic?

nik

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

Re: [LARTC] Problem with HTB and ceil

[Andreas Klauer]

On Tuesday 19 July 2005 15:51, you wrote:
> Just to make sure, when you talk about the sum you are talking about the
> sum of the minimum bitrates, not the sum of the ceil bitrates, right?

Yes. The only rules for the ceil should be that it's the same or bigger 
than the rate, and that it does not exceed the parent's ceil.

> ## non voip
> /sbin/tc class add dev $EXTIF parent 1:002 classid 1:101 htb rate
> 364kbit ceil 364 prio 1
                  ^ Unit is missing, might cause problems.

> ## ACK
> /sbin/tc class add dev $EXTIF parent 1:101 classid 1:200 htb rate
> 140kbit ceil 364kbit prio 1
> ## SSH
> /sbin/tc class add dev $EXTIF parent 1:101 classid 1:300 htb rate 16kbit
> ceil 364kbit prio 2
> ## http/https traffic
> /sbin/tc class add dev $EXTIF parent 1:101 classid 1:400 htb rate 16kbit
> ceil 364kbit prio 3
> ## bulk
> /sbin/tc class add dev $EXTIF parent 1:101 classid 1:500 htb rate 16kbit
> ceil 364kbit prio 4

This time, the sum is lower than the parent. This is not nearly as bad as 
having a too high sum; together with the prio it can even make sense if 
it's intentional. I'm just commenting because you should be aware of it, 
that's all. If this was my script, I'd add a comment explaining as to why 
it is done this way.

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

Re: [LARTC] Problem with HTB and ceil

[nik-da-39]

Andreas Klauer <Andreas.Klauer@metamorpher.de>:
> Yes. The only rules for the ceil should be that it's the same or bigger
> than the rate, and that it does not exceed the parent's ceil.

Thanks for the info. Its not clearly enough stated in the HTB "manual".

> > ## non voip
> > /sbin/tc class add dev $EXTIF parent 1:002 classid 1:101 htb rate
> > 364kbit ceil 364 prio 1
>                   ^ Unit is missing, might cause problems.

Yeah, I messed copy+paste again.

> This time, the sum is lower than the parent. This is not nearly as bad as
> having a too high sum; together with the prio it can even make sense if
> it's intentional. I'm just commenting because you should be aware of it,
> that's all. If this was my script, I'd add a comment explaining as to why
> it is done this way.

Thanks for your comment. From my understanding, I dont rely too much on the
exact minimum bitrate, as long as the prios are obeyed by the packets. Thats
why I also dont need the sum of the min bitrates to be exactly the parental
bitrate, if I understand it correctly the remaining abdnwidth after all minimum
requirements have been fullfilled will be spread proportionally according to the
allocations. So, for me its fine if the proportion would be kept. Anyhow, in
this special case this doesnt matter at all, cause I would like to have
priorized traff.

I think I will start a new thread as the original problem why I started this
thread is solved. And then I will make sure I post my original script with
comments etc.

nik

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

Re: [LARTC] Problem with HTB and ceil

[Andreas Klauer]

On Tuesday 19 July 2005 22:41, nik-da-39 wrote:
> Thanks for your comment. From my understanding, I dont rely too much on
> the exact minimum bitrate, as long as the prios are obeyed by the
> packets.

...

> Thats why I also dont need the sum of the min bitrates to be 
> exactly the parental bitrate, if I understand it correctly the remaining
> abdnwidth after all minimum requirements have been fullfilled will be
> spread proportionally according to the allocations.

...

I might've misunderstood you here, but just in case:

The HTB prio parameter affects borrowing priority, not packet priority.
Which basically means that the proportions which you'd get if all classes 
had the same priority, will look much different.

In other words, low priority classes will not get any bandwidth except 
their guaranteed rate, as long as a higher priority class is borrowing.

Personally, I only use the HTB prio for unwanted traffic class (P2P), 
because I find that for normal traffic, the restriction is too harsh.
This is why I recommend not using the HTB prio parameter at all in the 
beginning, and only start experimenting with it when you really need it.

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

Re: [LARTC] Problem with HTB and ceil

[nik-da-39]

Quoting Andreas Klauer <Andreas.Klauer@metamorpher.de>:

> I might've misunderstood you here, but just in case:
>
> The HTB prio parameter affects borrowing priority, not packet priority.

You mean priority after the guaranteed bitrates have been fullfilled.

> Which basically means that the proportions which you'd get if all classes
> had the same priority, will look much different.
>
> In other words, low priority classes will not get any bandwidth except
> their guaranteed rate, as long as a higher priority class is borrowing.

More precisely, after the guaranteed bandwidhts have been assigned the excess
bandwidth will be spread to the highest prio class first until the ceiling is
reached and then any remainin will be assigne to the next highes prio class and
the same procedure is repeated until the bandwidht is 0. Correct? If so, that is
exactly what I am trying to achieve.

> Personally, I only use the HTB prio for unwanted traffic class (P2P),
> because I find that for normal traffic, the restriction is too harsh.
> This is why I recommend not using the HTB prio parameter at all in the
> beginning, and only start experimenting with it when you really need it.

I think I really need it ;-)

But I  have observed something else, it looks like if I use two different IP A
and B where I sent packets to, and mark those packets with the correct
different marks, I can see how the prio works, one of the flows is almost drown
by the other as expected from my prio config. So, it _might_ be a problem in the
way how I tag the packets. If you remember I had the ACK class which should have
prio 1, and I matched them with following rules:

iptables -A POSTROUTING -t mangle -o $EXTIF -p tcp -m tcp --tcp-flags
SYN,RST,ACK ACK -m length --length :128 -j MARK --set-mark 200
iptables -A POSTROUTING -t mangle -o $EXTIF -p tcp -m tcp --tcp-flags !
SYN,RST,ACK ACK -m length --length :128 -j MARK --set-mark 200
iptables -A POSTROUTING -t mangle -o $EXTIF -p tcp -m length --length 0:48 -j
MARK --set-mark 200

Is it possible that still some ACKs are not marked correctly? And if so, how
would such a set of rules look like to catch all ACK packets?

Thanks for your help!

nik

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