drew einhorn wrote:
RTFM time. The htb section of http://lartc.org/howto/index.html is easier
reading than the cbq section. And the howto claims htb is better anyway.
Let's focus on the htb version of wondershaper.
Yes HTB/HFSC should br better for slow links, unfortunatly wondershaper
is flawed as noted below. This may not be your problem here, though.
Then we start downloading a file to generate some traffic that really
needs to be shaped.
Shaping from the wrong end of the bottleneck is not nice and the slower
the link the harder it is. It's better than not shaping (policing in
this case).
root@Devil:~ # sh -x wshaper.htb
+ DOWNLINK=100
+ UPLINK=100
+ DEV=eth0
+ NOPRIOHOSTSRC=
+ NOPRIOHOSTDST=
+ NOPRIOPORTSRC=
+ NOPRIOPORTDST=
+ '[' '' = status ']'
+ tc qdisc del dev eth0 root
+ tc qdisc del dev eth0 ingress
+ '[' '' = stop ']'
+ tc qdisc add dev eth0 root handle 1: htb default 20
It's not a good idea to use default on eth, unless you explicitly handle
arp. IIRC WS was tested on ppp so I guess thats why. Not specifying
default lets unclassified through unshaped and you can, and do make a
catchall ip filter later for 20 anyway.
+ tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbit burst 6k
+ tc class add dev eth0 parent 1:1 classid 1:10 htb rate 100kbit burst
6k prio 1
+ tc class add dev eth0 parent 1:1 classid 1:20 htb rate 90kbit burst 6k
prio 2
+ tc class add dev eth0 parent 1:1 classid 1:30 htb rate 80kbit burst 6k
prio 2
Rates can't add up to more than parent rate/ceil I guess the test case
used didn't expose this when WS was published. I would use something like -
... 1:10 htb rate 80kbit ceil 100kbit ...
1:20 htb rate 15kbit ceil 100kbit
1:30 htb rate 5kbit ceil 100kbit
+ tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
+ tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10
+ tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10
+ tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip
tos 0x10 0xff flowid 1:10
+ tc filter add dev eth0 parent 1:0 protocol ip prio 10 u32 match ip
protocol 1 0xff flowid 1:10
+ tc filter add dev eth0 parent 1: protocol ip prio 10 u32 match ip
protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2
match u8 0x10 0xff at 33 flowid 1:10
+ tc filter add dev eth0 parent 1: protocol ip prio 18 u32 match ip
dst 0.0.0.0/0 flowid 1:20
This filter should catch all IP so default not needed.
+ tc qdisc add dev eth0 handle ffff: ingress
+ tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 match ip
src 0.0.0.0/0 police rate 100kbit burst 10k drop flowid :1
I am suprised this did nothing - at low speeds you may need to back off
a bit more. If I were shaping 128kbit link I would be tempted to mss
clamp/set mtus lower as 1500byte packets have long bitrate latency -
depends on your requirememts and I am not sure you can mss clamp with
this bridge setup.
+ tc -s qdisc ls dev eth0
qdisc htb 1: r2q 10 default 20 direct_packets_stat 0
Sent 18649 bytes 191 pkts (dropped 0, overlimits 0)
qdisc sfq 10: parent 1:10 limit 128p quantum 1514b perturb 10sec
Sent 10582 bytes 147 pkts (dropped 0, overlimits 0)
qdisc sfq 20: parent 1:20 limit 128p quantum 1514b perturb 10sec
Sent 8067 bytes 44 pkts (dropped 0, overlimits 0)
qdisc sfq 30: parent 1:30 limit 128p quantum 1514b perturb 10sec
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
Looks OK, we are testing ingress anyway. I would use limit XX on sfqs as
128 default is a very long time @ low bitrates.
qdisc ingress ffff: ----------------
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
0 bytes - something wrong here. Filter looks OK, but it's not seeing
traffic. I haven't got a 2.4 box, I do have a br on a 2.6 box and just
tested on eth0 - works OK with those rules.
Counters on eth0 egress look OK so I assume all traffic is IP - tcpdump.
I wonder if it's something to do with bridging (I don't understand some
behavior of mine), maybe ingress on eth0 has a different ethertype at
that point.
Try this instead -
tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: protocol arp prio 1 u32 match u32 0
0 flowid :1
tc filter add dev eth0 parent ffff: protocol all prio 2 u32 match u32 0
0 police rate 100kbit burst 10k drop flowid :2
Aggh just thought of something else - tempted to delete above, but will
leave incase it works.
The thing is 2.4 and 2.6(default config) use different policers. On 2.4
it hooks after PREROUTING and on 2.6 before. Maybe old policer + bridge
isn't going to work for that reason.
Andy.
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
