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