I was just using an scp command. I figured as, with ingress, everything
goes into a single queue - it should show fairly relevant results - even
if it wasn't down to the tiniest fraction of precision.
On 09/05/13 10:51, Ian Macintosh wrote:
How are you testing the rate? If you're using some random protocol
that will cloud the issue. Try using raw tcp/udp via a test tool.
iperf comes to mind.
On 9 May 2013 09:57, Sebastian Arcus <shop@xxxxxxxxxxxx> 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.
--
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
--
Linux vehicle CCTV - www.open-t.co.uk/iroko
--
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
