Re: htb overrate with 2.6.16

Linux Advanced Routing and Traffic Control

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

 



On Sun, 2006-04-16 at 00:13 +0100, Andy Furniss wrote:
> Yanko Kaneti wrote:
> > Hi
> > 
> > Here is something that worked with with 2.6.10-1.771_FC2smp and stopped
> > working when I upgraded to 2.6.16-1.2069_FC4smp.
> > These are fedora kernels and the network controller is an Intel Gbit
> > (e1000) running a 100 Mbps Full Duplex.
> > Don't know how or if this matters but the 2.6.10 kernel has
> > CONFIG_X86_HZ=1000 and the 2.6.16 has CONFIG_HZ=250
> > 
> > The idea is to just shape to , say 2Mbit, a certain kind of traffic
> > everything else should goes unshaped.
> > 
> > # tc qdisc add dev eth0 root handle 1: htb default 20
> 
> Why default 20 - if you don't have 1:20 it would be better to use 
> default 0 which is unshaped and is the default - so ommitting default is 
> the same - unclassifed traffic goes through unshaped.

No reason. I obviously missed the explanation for the 0 class. Will omit
default in the future.

> > # tc class add dev eth0 parent 1: classid 1:2 htb rate 2Mbit
> > # tc qdisc add dev eth0 parent 1:2 sfq perturb 10
> > # tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 50 fw flowid 1:2
> > 
> > This was working as expected with 2.6.10
> > I've tried creating a proper 1:1 100Mbit parent to be the default but it
> > didn't help. And it was working fine without it on 2.6.10
> > 
> > With the 2.6.16 kernel I get results like
> > 
> > # tc -s -d class show dev eth0
> > class htb 1:2 root leaf 800b: prio 0 quantum 25000 rate 2000Kbit ceil 2000Kbit burst 2600b/8 mpu 0b overhead 0b cburst 2600b/8 mpu 0b overhead 0b level 0
> >  Sent 189796883 bytes 20626 pkt (dropped 0, overlimits 0 requeues 0)
> >  rate 3484Kbit 45pps backlog 0b 0p requeues 0
> >  lended: 20627 borrowed: 0 giants: 30926
> 
> The giants are the problem - if you specify mtu XXXXX on 1:2 class it 
> should work.

> Or you could consider setting mtu on nic to 1500 if that is practical 
> for you ie. this traffic is headed somewhere that is going to frag it 
> down to 1500 anyway.

Setting mtu 16500  for the class fixed it. But I wonder where did these
giants come from in the first place? The mtu of the interface is and was
1500. Or so ifconfig and ip link tell me. Or this is some other mtu we
are talking about...


Thanks
Yanko

_______________________________________________
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