Lonney wrote:
Hi Ben,
Thanks for the reply.
I have just managed to get this working how I wanted, based on an
example I found here
http://forums.opensuse.org/english/get-technical-help-here/network-internet/454307-wondershaper-modification-exclude-lan-should-included.html
This is the script I came up with..
http://pastebin.com/6wJ4eVnd
With some quick tests it appears to work as expected.
HTB wondershaper is ancient and was written before htb even got into
kernel IIRC.
It is actually flawed, but the author was never contactable to correct it.
In practice with the filter rules given and sfq on the leafs it will
usually work, but anything derived/modified from it has the potential to
fail.
The main issue is -
tc class add dev $DEV parent 1: classid 1:1 htb rate ${UPLINK}kbit burst 6k
# High prio class 1:10:
tc class add dev $DEV parent 1:1 classid 1:10 htb rate ${UPLINK}kbit \
burst 6k prio 1
# Bulk & default class 1:20 - gets slightly less traffic,
# and a lower priority:
tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[9*$UPLINK/10]kbit \
burst 6k prio 2
With htb the rate on the parent class does not cap the rates on the
leafs. so potentially it will go over.
I would change this to (untested so may fail due to my rustyness)
tc class add dev $DEV parent 1:1 classid 1:10 htb rate
${9*UPLINK/10}kbit ceil ${UPLINK}kbit burst 6k prio 0
tc class add dev $DEV parent 1:1 classid 1:20 htb rate ${UPLINK/10}kbit
ceil ${UPLINK}kbit burst 6k prio 1
This changes rate for bulk slightly so UPLINK may need reducing.
If you know the exact details of your wan it's possible to set overheads
so for egress you can push to near 100%. This doesn't wirk for ingress
as you have to sacrifice bandwidth to have any effect.
IIRC prio 0 is top for htb - it isn't for filters 1 is.
Issue 2 - the use of htb default on eth.
wondershaper was tested on ppp so it didn't matter then, also the sfq on
the bulk class will save the day.
The issue is that arp will be sent to a low prio class which if sfq were
omitted/changed to [b]fifo maybe even red there would be potential for
it to be dropped/delayed too long, which is not good :-)
more minor issues -
quantum 1500 on eth tc sees 1500 byte ip packets as 1514
LAN_SPEED if you really wanted to limit with this set to 100/1000 you
would have find/set what the overheads are or just back off a bit.
filters -
If dns doesn't get caught by the tos filter giving prio would be nice,
but again sfq will help it.
The filter that matches acks always seemed a bit odd to me given almost
every tcp packet has the ack bit set anyway matching it seems only to
exclude syns etc that should also be prio, 64 may also be smaller than
some sacks.
The policer -
# Filter *everything* to it (0.0.0.0/0), drop everything that's
# coming in too fast:
tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1
Well luckily the comment is wrong as protocol ip means that you only
filter ipv4 - which is good.
policers are crude, can be aggressive and won't do any fairness - as
Benjamin has said ifb can let you shape properly, but you don't get the
help of iptables.
There have been recent posts regarding policers and gso (generic
segmentation offload) ethtool -k will show offloads enabled for your
nic. If you get poor throughput you may need to turn it off or add
mtu 3100
to the policer line after burst 10k.
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
