Hello, I''m trying to setup what I thought would be a fairly basic tiered shaping system. I have a 6mbit (768kbps) link coming into my eth1 device, with my LAN IPs on the eth0 device. I want to limit outgoing traffic so that certain IPs are limited to 400kbps, with 3 classes under that 400k so certain machines get prioritized (main servers in 1:21, other servers in 1:22, workstations in 1:23) The problem is that when I turn this on, my packet latency jumps up by 50 to 100 times the normal rate. I go from 10-20 ms ping times to 500-1600ms! I''ve tried putting SFQ qdiscs under the classes, but that makes no difference. I''m sure there is just some tuning parameter I''m not setting correctly, but can somebody clue me in to what I''m doing wrong? Or is HTB just the wrong scheduler to be using here? I tried CBQ, but I can''t get the tiers to work ( I keep getting RTNETLINK answers: Invalid argument) I''m currently using a single tiered CBQ solution, but it really doesn''t fit my needs. Here''s the full script: ----------------------- qdisc add dev eth1 root handle 1: htb default 10 class add dev eth1 parent 1: classid 1:1 htb rate 768kbps class add dev eth1 parent 1: classid 1:10 htb rate 250kbps ceil 768kbps burst 6k class add dev eth1 parent 1: classid 1:20 htb rate 100kbps ceil 400kbps burst 6k class add dev eth1 parent 1:20 classid 1:21 htb rate 75kbps ceil 375kbps burst 6k filter add dev eth1 parent 1: protocol ip prio 16 u32 match ip src 192.168.1.35 flowid 1:21 filter add dev eth1 parent 1: protocol ip prio 16 u32 match ip src 192.168.1.29 flowid 1:21 filter add dev eth1 parent 1: protocol ip prio 16 u32 match ip src 192.168.1.28 flowid 1:21 filter add dev eth1 parent 1: protocol ip prio 16 u32 match ip src 192.168.1.16 flowid 1:21 class add dev eth1 parent 1:20 classid 1:22 htb rate 15kbps ceil 350kbps burst 6k filter add dev eth1 parent 1: protocol ip prio 16 u32 match ip src 192.168.1.30 flowid 1:22 filter add dev eth1 parent 1: protocol ip prio 16 u32 match ip src 192.168.1.31 flowid 1:22 filter add dev eth1 parent 1: protocol ip prio 16 u32 match ip src 192.168.1.32 flowid 1:22 filter add dev eth1 parent 1: protocol ip prio 16 u32 match ip src 192.168.1.36 flowid 1:22 filter add dev eth1 parent 1: protocol ip prio 16 u32 match ip src 192.168.1.39 flowid 1:22 filter add dev eth1 parent 1: protocol ip prio 16 u32 match ip src 192.168.1.40 flowid 1:22 filter add dev eth1 parent 1: protocol ip prio 16 u32 match ip src 192.168.1.47 flowid 1:22 class add dev eth1 parent 1:20 classid 1:23 htb rate 10kbps ceil 200kbps burst 6k filter add dev eth1 parent 1: protocol ip prio 16 u32 match ip src 192.168.1.33 flowid 1:23 filter add dev eth1 parent 1: protocol ip prio 16 u32 match ip src 192.168.1.34 flowid 1:23 filter add dev eth1 parent 1: protocol ip prio 16 u32 match ip src 192.168.1.37 flowid 1:23
ISN Support Staff wrote:> Hello, > > I''m trying to setup what I thought would be a fairly basic tiered > shaping system. I have a 6mbit (768kbps) link coming into my eth1 > device, with my LAN IPs on the eth0 device. I want to limit outgoing > traffic so that certain IPs are limited to 400kbps, with 3 classes under > that 400k so certain machines get prioritized (main servers in 1:21, > other servers in 1:22, workstations in 1:23) > > The problem is that when I turn this on, my packet latency jumps up by > 50 to 100 times the normal rate. I go from 10-20 ms ping times to > 500-1600ms! I''ve tried putting SFQ qdiscs under the classes, but that > makes no difference. > > I''m sure there is just some tuning parameter I''m not setting > correctly, but can somebody clue me in to what I''m doing wrong? Or is > HTB just the wrong scheduler to be using here? I tried CBQ, but I can''t > get the tiers to work ( I keep getting RTNETLINK answers: Invalid > argument) I''m currently using a single tiered CBQ solution, but it > really doesn''t fit my needs. > > Here''s the full script: > ----------------------- > qdisc add dev eth1 root handle 1: htb default 10Using htb default will send arp to a really long (in this case) backlogged queue, which could cause problems. Generally you need to classify low latency traffic to different class than bulk if you want it to stay low latency. I am suprised sfq didn''t help - maybe you also need to back off the ceils to allow for overheads on the quoted link speed. Andy.