[LARTC] HTB performance improvement

[LARTC] HTB performance improvement

[Koblensky Mingyur]

[-- Attachment #1: Type: text/html, Size: 5244 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

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

Re: [LARTC] HTB performance improvement

[gypsy]

> Koblensky Mingyur wrote:
> 
> Hi all !
> i'm looking at the performance of the HTB algorithm/implementation
> because i would like more packets/sec !!
> this is the scenario of the performance test:
> 
> i'm using an embedded system with:
> SPEED CPU: 399,999 MHz
> RAM: 128 MByte
> FLASH: 16 MByte
> EEPROM: 8Kbyte
> PROCESSOR MPC8272
> 
> 1) with none qos configuration (system conf) i've obtained:  TX
> 29940 packets/sec RX 29948.98 packets/sec with 2 packets lost
> 2) with only system conf + iptables marking support          TX/RX
> 24950 packets/sec, 8 packets lost
> 3) with only system conf + u32 support                       TX/RX
> 29950 packets/sec, 5 packets lost
> 4) with only system conf + HTB with iptables mark classifier TX/RX
> 13000 packets/sec, 0 packets lost
> 5) with only system conf + HTB with u32 classifier           TX/RX
> 19290 packets/sec, 0 packets lost
> 
> tc qdisc add dev eth0.2 root handle 1: htb
> tc class add dev eth0.2 parent 1: classid 1:1 htb  rate 100000000 ceil
> 100000000 burst 1000000 quantum 1600
> tc class add dev eth0.2 parent 1:1 classid 1:10 htb prio 1 rate
> 70000000 ceil 70000000 burst 1000000 quantum 1600
> tc class add dev eth0.2 parent 1:1 classid 1:11 htb prio 2 rate
> 10000000 ceil 10000000 burst 1000000 quantum 1600
> tc class add dev eth0.2 parent 1:1 classid 1:12 htb prio 3 rate
> 10000000 ceil 10000000 burst 1000000 quantum 1600


First, your quantum is wrong.  Think of HTB as a NIC.  You are sending
packets out via that "NIC", and those packets must be 1600 bytes big
before being sent.  Since a "normal" packet is up to 1500 bytes, you're
making HTB take part of the next packet before it can send.

Your burst is also huge enough to swamp the interrupt controller. 
Consider 16K or 32K instead.

Unless you get complaints during the load of the above, do not specify
any quantum, or specify the quantum HTB sets for rates that do not
complain.

The next likely reason for you to be at "half spped" is that HTB is
using the wrong clock.  Which clock and what speed are kernel version
dependent.

Part of what I snipped referred to 10/100 ethernet.  Normally that will
not trigger any, but be sure that when you run a 'tc -s class ls dev
$IFE' (where IFE is the correct interface) that "giants" are always
zero.
--
gypsy
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] HTB performance improvement

[gypsy]

gypsy wrote:
> 
> > tc qdisc add dev eth0.2 root handle 1: htb
> > tc class add dev eth0.2 parent 1: classid 1:1 htb  rate 100000000 ceil
> > 100000000 burst 1000000 quantum 1600
> > tc class add dev eth0.2 parent 1:1 classid 1:10 htb prio 1 rate
> > 70000000 ceil 70000000 burst 1000000 quantum 1600
> > tc class add dev eth0.2 parent 1:1 classid 1:11 htb prio 2 rate
> > 10000000 ceil 10000000 burst 1000000 quantum 1600
> > tc class add dev eth0.2 parent 1:1 classid 1:12 htb prio 3 rate
> > 10000000 ceil 10000000 burst 1000000 quantum 1600

I just noticed that you're trying to shape "aliases".  You can't.  You
must shape eth0 because you can't shape eth0.2.  I'm just repeating what
I've heard/read, so do your own research.  But I bet you a quarter I'm
right :)
--
gypsy
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] HTB performance improvement

[Andy Furniss]

gypsy wrote:
> gypsy wrote:
>>> tc qdisc add dev eth0.2 root handle 1: htb
>>> tc class add dev eth0.2 parent 1: classid 1:1 htb  rate 100000000 ceil
>>> 100000000 burst 1000000 quantum 1600
>>> tc class add dev eth0.2 parent 1:1 classid 1:10 htb prio 1 rate
>>> 70000000 ceil 70000000 burst 1000000 quantum 1600
>>> tc class add dev eth0.2 parent 1:1 classid 1:11 htb prio 2 rate
>>> 10000000 ceil 10000000 burst 1000000 quantum 1600
>>> tc class add dev eth0.2 parent 1:1 classid 1:12 htb prio 3 rate
>>> 10000000 ceil 10000000 burst 1000000 quantum 1600
> 
> I just noticed that you're trying to shape "aliases".  You can't.  You
> must shape eth0 because you can't shape eth0.2.  I'm just repeating what
> I've heard/read, so do your own research.  But I bet you a quarter I'm
> right :)
> --

Could be vlans - in which case OP could try adding child b/pfifos to the 
leafs and use the limit parameter to specify buffer length.

HTB and HFSC both pick up default queuelengths from the device, but it's 
0 on vlans (they use 2 or 3 packet pfifos IIRC in this case).

I do notice there are no drops in the stats though, but it's still worth 
specifying queue length and type in the script.

Andy.

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