On 09/05/13 09:57, 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 have just retried the exact same settings, but on a real server with
an ADSL connection to the internet (well, actually an ethernet
connection which goes through an ADSL router). On this server, the
ingress policing is working perfectly fine. Maybe the KVM vm's or the
virtio network interface is playing havoc with tc?
The real server has kernel 2.6.38 - while the vm has 3.8.4. Could the
kernel version be an issue? Have there been changes in traffic
shaping/policing code in newer kernels? Could there be other settings
which are interfering with the ingress policing? Maybe the MRU on the
interface?
--
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
