Why are my cburst settings ignored?

Why are my cburst settings ignored?

[maillinglistredcap]

Hi there,

I'm new to this list and new to traffic control as well. I want to do some traffic 
shaping on my home network and over the past few days I've studied the subject
quite a lot. Today I decided to some first experiments on my network using the 
HTB queueing discpline which seems to suit my purposes best. Well the first 
results were disappointing... most likely due to my lack of knowledge. I tried 
to improve the result by tinkering with the burst and cburst parameters of HTB
only to find that my cburst settings don't have any effect at all. 

parzival traffic # tc qdisc del dev eth0 root 2>/dev/null 
parzival traffic # tc qdisc add dev eth0 root handle 1: htb default 110
parzival traffic # tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbit 
burst 1650b cburst 1800b
parzival traffic # tc -s class show dev eth0
class htb 1:1 root prio 0 rate 100000bit ceil 100000bit burst 1650b cburst 
1650b 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 0bit 0pps backlog 0b 0p requeues 0 
 lended: 0 borrowed: 0 giants: 0
 tokens: 2062500 ctokens: 2250000



Can anyone shed some light on why this is happening?

Cheers and thanks in advance :-).

Re: Why are my cburst settings ignored?

[Andrew Beverley]

On Sat, 2013-07-06 at 18:23 +0200, maillinglistredcap@gmx.de wrote:
> Hi there,
> 
> I'm new to this list and new to traffic control as well. I want to do some traffic 
> shaping on my home network and over the past few days I've studied the subject
> quite a lot. Today I decided to some first experiments on my network using the 
> HTB queueing discpline which seems to suit my purposes best. Well the first 
> results were disappointing... most likely due to my lack of knowledge.

You're not sending any traffic into your single leaf class.

> I tried to improve the result by tinkering with the burst and cburst
> parameters of HTB only to find that my cburst settings don't have any
> effect at all. 

I wouldn't worry about these settings for the moment.

> parzival traffic # tc qdisc del dev eth0 root 2>/dev/null 
> parzival traffic # tc qdisc add dev eth0 root handle 1: htb default 110

You're setting the default class to be the one with minor ID 110, but
there is no class with this ID so the traffic does not go anywhere.

> parzival traffic # tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbit 
> burst 1650b cburst 1800b

Set the classid to be 1:110 instead.

> parzival traffic # tc -s class show dev eth0
> class htb 1:1 root prio 0 rate 100000bit ceil 100000bit burst 1650b cburst 
> 1650b 
>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
>  rate 0bit 0pps backlog 0b 0p requeues 0 
>  lended: 0 borrowed: 0 giants: 0
>  tokens: 2062500 ctokens: 2250000

The stats above show that no traffic is going through the qdisc (note
all the zeros).

Andy

Re: Why are my cburst settings ignored?

[maillinglistredcap]

Hi Andy,


Am Montag, 8. Juli 2013, 22:27:03 schrieb Andrew Beverley:
> On Sat, 2013-07-06 at 18:23 +0200, maillinglistredcap@gmx.de wrote:
> > Hi there,
> > 
> > I'm new to this list and new to traffic control as well. I want to do some
> > traffic shaping on my home network and over the past few days I've
> > studied the subject quite a lot. Today I decided to some first
> > experiments on my network using the HTB queueing discpline which seems to
> > suit my purposes best. Well the first results were disappointing... most
> > likely due to my lack of knowledge.
> You're not sending any traffic into your single leaf class.

Yes, I'm aware of that. I posted only a part of my configurations to illustrate 
the fact, that cburst settings are ignored. But maybe it's more useful if I 
give the whole configuration.

My qdisc tree is as follows:

tc qdisc del dev eth0 root 2>/dev/null 
tc qdisc add dev eth0 root handle 1: htb default 110
tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit cburst 1602b

tc class add dev eth0 parent 1:1 classid 1:10 htb rate 99780kbit
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 220kbit

tc class add dev eth0 parent 1:11 classid 1:110 htb rate 180kbit ceil 220kbit 
tc class add dev eth0 parent 1:11 classid 1:111 htb rate  40kbit ceil 220kbit


This tree is on a machine in my network that has only one NIC. There is also a 
router on my network with a 224 kbit uplink internet connection. I run some 
services on the machine (e.g. bittorrent) that tend to clog up my internet 
connection. My approach is to direct all local traffic to the class with minor 
ID 10. Other traffic should be handled by class 1:11. In this class I have two 
subclasses. One for services were responsiveness is crucial ( classid 1:110) 
and a class (classid 1:111) that should handle other traffic (e.g. bittorrent). 
Here is my iptables configuration:

iptables -t mangle -N lantraffic
iptables -t mangle -A lantraffic -j CLASSIFY --set-class 1:10
iptables -t mangle -A lantraffic -j ACCEPT                                                                                                                                                       
                                                                                                                                                                                                 
iptables -t mangle -N wantraffic                                                                                                                                                                 
iptables -t mangle -A wantraffic -o eth0 -p tcp -m length --length :64 -j 
CLASSIFY --set-class 1:110                                                                                             
iptables -t mangle -A wantraffic -o eth0 -m owner --uid-owner torrent -j 
CLASSIFY --set-class 1:111                                                                                                  
iptables -t mangle -A wantraffic -j ACCEPT    

iptables -t mangle -A POSTROUTING -o eth0 -d 192.168.2.0/24 -j lantraffic                                                                                                                        
iptables -t mangle -A POSTROUTING -o eth0 ! -d 192.168.2.0/24 -j wantraffic


However, these settings don't work as I intended. Most of the time loading 
websites is very slow ( I also have privoxy running on the machine, so the 
above qdiscs should apply to HTTP/S traffic on my network). 


Here are my statistics after about 5 minutes of websurfing with the qdisc 
active:

parzival traffic #  tc -s class show dev eth0
class htb 1:11 parent 1:1 rate 220000bit ceil 220000bit burst 1599b cburst 
1599b 
 Sent 7098894 bytes 20291 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 151240bit 29pps backlog 0b 0p requeues 0 
 lended: 3784 borrowed: 0 giants: 0
 tokens: -42215522 ctokens: -42215522

class htb 1:110 parent 1:11 prio 0 rate 180000bit ceil 220000bit burst 1599b 
cburst 1955b 
 Sent 1383696 bytes 14676 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 8616bit 11pps backlog 0b 0p requeues 0 
 lended: 14628 borrowed: 48 giants: 0
 tokens: 68710977 ctokens: 69147340

class htb 1:111 parent 1:11 prio 0 rate 40000bit ceil 220000bit burst 1600b 
cburst 8800b 
 Sent 5715198 bytes 5615 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 142624bit 17pps backlog 0b 14p requeues 0 
 lended: 1879 borrowed: 3736 giants: 0
 tokens: -129515223 ctokens: 219603486

class htb 1:1 root rate 100000Kbit ceil 100000Kbit burst 1600b cburst 1600b 
 Sent 27883416 bytes 37148 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 389912bit 52pps backlog 0b 0p requeues 0 
 lended: 0 borrowed: 0 giants: 0
 tokens: 118880 ctokens: 118880

class htb 1:10 parent 1:1 prio 0 rate 99780Kbit ceil 99780Kbit burst 1596b 
cburst 1596b 
 Sent 20784522 bytes 16857 pkt (dropped 0, overlimits 0 requeues 0) 
 rate 238680bit 24pps backlog 0b 0p requeues 0 
 lended: 16857 borrowed: 0 giants: 0
 tokens: 118860 ctokens: 118860


As stated above, websurfing was not very responsive most of the time. I don't 
know the exact implications of the burst and cburst parameters but I noticed 
that the cburst in class 1:111 is quite large (8800b). The rule of thumb for 
cburst seems to be to choose it as close to MTU as possible (1500 in my case).  
As far as I understand, a high cburst setting implies that the class can break 
its ceil rate on the expense of its siblings and the higher the cburst the 
longer the time the class can operate above its ceil rate. I was wondering if 
this is the reason for the poor performance. Unfortunately,  cburst settings 
specified by me are simply ignored by tc and so I have no idea how to 
investigate further :-(.

Cheers

redcap

Re: Why are my cburst settings ignored?

[Andrew Beverley]

> > You're not sending any traffic into your single leaf class.
> 
> Yes, I'm aware of that. I posted only a part of my configurations to illustrate 
> the fact, that cburst settings are ignored.

Ah okay, I assumed that your statement saying that it didn't work
properly before applying the cburst setting meant that it didn't work at
all.

> My qdisc tree is as follows:
> 
> tc qdisc del dev eth0 root 2>/dev/null 
> tc qdisc add dev eth0 root handle 1: htb default 110
> tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit cburst 1602b
> 
> tc class add dev eth0 parent 1:1 classid 1:10 htb rate 99780kbit
> tc class add dev eth0 parent 1:1 classid 1:11 htb rate 220kbit
> 
> tc class add dev eth0 parent 1:11 classid 1:110 htb rate 180kbit ceil 220kbit 
> tc class add dev eth0 parent 1:11 classid 1:111 htb rate  40kbit ceil 220kbit

With a quick glance, all looks good.

> This tree is on a machine in my network that has only one NIC. There is also a 
> router on my network with a 224 kbit uplink internet connection. I run some 
> services on the machine (e.g. bittorrent) that tend to clog up my internet 
> connection.

I assume you're only shaping egress traffic from your machine? Are you
sure that the problems are not also caused by ingress traffic?

>  My approach is to direct all local traffic to the class with minor 
> ID 10. Other traffic should be handled by class 1:11. In this class I have two 
> subclasses. One for services were responsiveness is crucial ( classid 1:110) 
> and a class (classid 1:111) that should handle other traffic (e.g. bittorrent). 

All makes sense.

> Here is my iptables configuration:
> 
> iptables -t mangle -N lantraffic
> iptables -t mangle -A lantraffic -j CLASSIFY --set-class 1:10
> iptables -t mangle -A lantraffic -j ACCEPT                                                                                                                                                       
>                                                                                                                                                                                                  
> iptables -t mangle -N wantraffic                                                                                                                                                                 
> iptables -t mangle -A wantraffic -o eth0 -p tcp -m length --length :64 -j 
> CLASSIFY --set-class 1:110                                                                                             
> iptables -t mangle -A wantraffic -o eth0 -m owner --uid-owner torrent -j 
> CLASSIFY --set-class 1:111                                                                                                  
> iptables -t mangle -A wantraffic -j ACCEPT    
> 
> iptables -t mangle -A POSTROUTING -o eth0 -d 192.168.2.0/24 -j lantraffic                                                                                                                        
> iptables -t mangle -A POSTROUTING -o eth0 ! -d 192.168.2.0/24 -j wantraffic

I assume that you're happy that all traffic is being classified
correctly, based on your statistics below?

> However, these settings don't work as I intended. Most of the time loading 
> websites is very slow ( I also have privoxy running on the machine, so the 
> above qdiscs should apply to HTTP/S traffic on my network). 

It might be worth reducing your overall rate below 220kbit. Whilst you
state that the link is 224kbit, if for any reason you get slightly below
this then the router will start to shape/buffer the traffic in a manner
that you don't want. You need to make sure that *all* shaping/queueing
is done within HTB.

It would be worth using tc-viewer to see exactly what is happening:

http://tccs.sourceforge.net/

> Here are my statistics after about 5 minutes of websurfing with the qdisc 
> active:

[...]

> As stated above, websurfing was not very responsive most of the time. I don't 
> know the exact implications of the burst and cburst parameters but I noticed 
> that the cburst in class 1:111 is quite large (8800b). The rule of thumb for 
> cburst seems to be to choose it as close to MTU as possible (1500 in my case).  

My gut feeling is that the cburst setting will not be causing your
problems. I have never played with the setting - it always works at the
default for me, and problems I experience are normally due to the sort
of issues described above.

That said, I read some stuff recently that cburst values do sometimes
not work correctly with some MTU settings, but I forget the exact
details. Someone else on this list may know (or it might be in the
archives).

Andy

Re: Why are my cburst settings ignored?

[Andy Furniss]

maillinglistredcap@gmx.de wrote:
> Hi there,
>
> I'm new to this list and new to traffic control as well. I want to do some traffic
> shaping on my home network and over the past few days I've studied the subject
> quite a lot. Today I decided to some first experiments on my network using the
> HTB queueing discpline which seems to suit my purposes best. Well the first
> results were disappointing... most likely due to my lack of knowledge. I tried
> to improve the result by tinkering with the burst and cburst parameters of HTB
> only to find that my cburst settings don't have any effect at all.
>
> parzival traffic # tc qdisc del dev eth0 root 2>/dev/null
> parzival traffic # tc qdisc add dev eth0 root handle 1: htb default 110
> parzival traffic # tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbit
> burst 1650b cburst 1800b
> parzival traffic # tc -s class show dev eth0
> class htb 1:1 root prio 0 rate 100000bit ceil 100000bit burst 1650b cburst
> 1650b
>   Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>   rate 0bit 0pps backlog 0b 0p requeues 0
>   lended: 0 borrowed: 0 giants: 0
>   tokens: 2062500 ctokens: 2250000

I don't know how it works exactly, but in this example as the rate and 
ceil are the same you get the same.

HTB seems to only allow certain values related to bandwidth of the 
rate/ceil and possibly r2q/quantum.

Testing your example with burst and cburst at 10b (as I once used this 
long ago) gives 10b and 10b, but changing ceil to 200kbit gives 10b and 20b.

I would only ever set low values on low bandwidth bulk classes.

Re: Why are my cburst settings ignored?

[Andy Furniss]

maillinglistredcap@gmx.de wrote:
> Hi Andy,
>
>
> Am Montag, 8. Juli 2013, 22:27:03 schrieb Andrew Beverley:
>> On Sat, 2013-07-06 at 18:23 +0200, maillinglistredcap@gmx.de wrote:
>>> Hi there,
>>>
>>> I'm new to this list and new to traffic control as well. I want to do some
>>> traffic shaping on my home network and over the past few days I've
>>> studied the subject quite a lot. Today I decided to some first
>>> experiments on my network using the HTB queueing discpline which seems to
>>> suit my purposes best. Well the first results were disappointing... most
>>> likely due to my lack of knowledge.
>> You're not sending any traffic into your single leaf class.
>
> Yes, I'm aware of that. I posted only a part of my configurations to illustrate
> the fact, that cburst settings are ignored. But maybe it's more useful if I
> give the whole configuration.
>
> My qdisc tree is as follows:
>
> tc qdisc del dev eth0 root 2>/dev/null
> tc qdisc add dev eth0 root handle 1: htb default 110

arp will go here and because you don't specify a child qdisc on 110 it 
could hypothetically get stuck in a very long and slow draining queue 
which could cause the eth to effectively stop working.

> tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit cburst 1602b

Fast eth is only 100mbit if you take into account overheads - I can't 
remember the number, but this won't shape.

The cburst here is ignored - burst may work but I wouldn't use it as it 
may just cause pointless work at 100mbit.

In fact when I shaped for slow wan on eth I didn't bother including lan 
traffic - if your lan is not maxed a lot then I would just use default 0 
(or not specify default) and only classify wan traffic to htb so lan/arp 
isn't shaped at all.

> tc class add dev eth0 parent 1:1 classid 1:10 htb rate 99780kbit
> tc class add dev eth0 parent 1:1 classid 1:11 htb rate 220kbit
>
> tc class add dev eth0 parent 1:11 classid 1:110 htb rate 180kbit ceil 220kbit
> tc class add dev eth0 parent 1:11 classid 1:111 htb rate  40kbit ceil 220kbit
>
>
> This tree is on a machine in my network that has only one NIC. There is also a
> router on my network with a 224 kbit uplink internet connection.

As Andrew has said - being too close to 224 without allowing for 
overheads will cause failiure. You can allow for the overheads and then 
220kbit would be OK. What and how to allow for the overheads depends on 
the precice details of your link - eg. dsl and also how you connect eg, 
pppoa, pppoe and even within those there are variants that have 
different overheads.

  I run some
> services on the machine (e.g. bittorrent) that tend to clog up my internet
> connection. My approach is to direct all local traffic to the class with minor
> ID 10. Other traffic should be handled by class 1:11. In this class I have two
> subclasses. One for services were responsiveness is crucial ( classid 1:110)
> and a class (classid 1:111) that should handle other traffic (e.g. bittorrent).
> Here is my iptables configuration:
>
> iptables -t mangle -N lantraffic
> iptables -t mangle -A lantraffic -j CLASSIFY --set-class 1:10
> iptables -t mangle -A lantraffic -j ACCEPT
>
> iptables -t mangle -N wantraffic
> iptables -t mangle -A wantraffic -o eth0 -p tcp -m length --length :64 -j
> CLASSIFY --set-class 1:110
> iptables -t mangle -A wantraffic -o eth0 -m owner --uid-owner torrent -j
> CLASSIFY --set-class 1:111
> iptables -t mangle -A wantraffic -j ACCEPT
>
> iptables -t mangle -A POSTROUTING -o eth0 -d 192.168.2.0/24 -j lantraffic
> iptables -t mangle -A POSTROUTING -o eth0 ! -d 192.168.2.0/24 -j wantraffic
>

If there is bulk upload traffic in 110 then things will still be slow as 
your dns/acks are being mixed in. Putting sfq on will help.

Re: Why are my cburst settings ignored?

[maillinglistredcap]

Thanks Andrew and Andy,

after I read your suggestions I made some changes to my setup. Specifically, I 
changed to rate settings on the root of the class tree to take traffic overhead 
into account. I also lowered the rate in the 1:11 node to make sure that traffic 
is shaped by my machine and not by the router. Well, as it turned out this 
lead to much improved performance. So, thanks again :-).


> In fact when I shaped for slow wan on eth I didn't bother including lan
> traffic - if your lan is not maxed a lot then I would just use default 0
> (or not specify default) and only classify wan traffic to htb so lan/arp
> isn't shaped at all.
> 

Just out of curiosity, how is traffic handled that isn't assigned to any class
in the qdisc tree when you do not specify a default class? My assumptions was 
that such pakets are simply be dropped, which is why I also shaped lan traffic.

Re: Why are my cburst settings ignored?

[Andrew Beverley]

On Sun, 2013-07-14 at 19:33 +0200, maillinglistredcap@gmx.de wrote:
> Thanks Andrew and Andy,

You're welcome.

> Just out of curiosity, how is traffic handled that isn't assigned to any class
> in the qdisc tree when you do not specify a default class? My assumptions was 
> that such pakets are simply be dropped, which is why I also shaped lan traffic.

AFAIK it just bypasses the whole of the qdisc and therefore goes through
the networking system completely unaffected. In the case of local LAN
traffic that you don't want to shape (which is not affected by any
associated bandwidth constraints) you can therefore keep it out of the
qdisc completely (although make sure you're not accidentally capturing
it with a "default" parameter).

Re: Why are my cburst settings ignored?

[Andy Furniss]

Andrew Beverley wrote:
> On Sun, 2013-07-14 at 19:33 +0200, maillinglistredcap@gmx.de wrote:
>> Thanks Andrew and Andy,
>
> You're welcome.
>
>> Just out of curiosity, how is traffic handled that isn't assigned to any class
>> in the qdisc tree when you do not specify a default class? My assumptions was
>> that such pakets are simply be dropped, which is why I also shaped lan traffic.
>
> AFAIK it just bypasses the whole of the qdisc and therefore goes through
> the networking system completely unaffected. In the case of local LAN
> traffic that you don't want to shape (which is not affected by any
> associated bandwidth constraints) you can therefore keep it out of the
> qdisc completely (although make sure you're not accidentally capturing
> it with a "default" parameter).

Yea, though it's still counted by HTB.

I should really specify "just for HTB" whenever I go on about not using 
default and arp.

HFSC is the opposite and does drop unclassified - so you really need a 
default, or to be careful to make sure arp is classified.