Sebastian Arcus wrote:
I'm trying to limit the bandwidth on the ingress leg of my Internet
connection. I'm using the code from lartc.org:
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 500kbit \
burst 10k drop flowid :1
I've tried rates of 1Mbit, 10Mbit, 100Mbit. I've tried bursts of 1k,
10k, 100k, 1000k. Nothing seems to make any difference. The test
download starts at about 20Mbytes/second - then keeps on slowing down
and stalling intermittently all the way down to 6kbytes/second. Then it
bobs up and down, stalling all the time, between 5kbytes/second and
17kbytes/second. There seems to be absolutely no relation between the
rate I set and the resulting download rate.
I'm testing on two VM's. With no traffic shaping on, I get about 36
megabytes/second clean speed between the two vms. Kernel on both sides
is 3.8.4. I'm only applying traffic shaping on one of the vm's.
Any suggestions would be much appreciated. I ran out of ideas so far.
I've reread the tc-htb man page, searched google on the ingress queue -
but can't see what am I missing.
I've never tested with a virtual machine so don't know exactly what to
do. The issue is that by default the kernel/driver will aggregate
inbound packets into larger ones and this doesn't work well with
policers default mtu setting as it drops them.
I have suggested mtu 3100 in the past as an extra parameter as it
happened to work on a quick test on a real 100m nic - maybe for vm you
need to go higher, or just turn off any sort of offload for the virtual
device with ethtool and see if that helps.
ethtool -k <devname>
to see what the settings are (generic-receive-offload is likely the
culprit) and eg.
ethtool -K <devname> gro off
--
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
