Hi,
I am still struggling with details on this setup. I have the shaping work
well with some applications and not with others. Here's what I have:
#!/bin/bash
tc qdisc add dev eth0 root handle 1: htb default 20
tc class add dev eth0 parent 1: classid 1:1 htb rate 800kbit burst 15k
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 650kbit ceil
110kbps burst 15k prio 0
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 150kbit ceil
110kbps burst 6k prio 1
tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10
U32="tc filter add dev eth0 protocol ip parent 1:0 prio 0 u32"
$U32 match ip sport 5001 0xffff match ip protocol 17 0xff flowid 1:10
It is supposed to prioritize traffic going through an openvpn tunnel which
uses port 5001 on both sides using udp packets.
Now when I use scp to upload a file across the tunnel, and at the same
time try and upload something somewhere totally different, it works like a
charme. The tunnel takes it all (not quite but almost), which is what I
want.
If I now use ftp instead, the results are somewhat varied. i.e. the ftp
upload through the tunnel shows up in the right class (1:10), however it
does not seem to want to grab the whole bandwidth. Thus leaving more than
the prior example with scp to 1:20.
My question is really if this is normal behaviour, or if I need to
continue to find a flaw in my thinking. The same thing happens using wget
from the other side of the tunnel (thus uploading to the other side),
where again, it does not utilize the full bandwidth.
I thought it might have something to do with the tos set to 0x8 when using
scp. So I set the tos flag using iptables for all the traffic going
throught the tunnel (which works, I can see it in tcpdump -i tun0). It
improved the situation a little bit, but not too much.
Can I expect the same behaviour that scp shows with all other
applications, or does the application decide how much bandwidth to grab?
Or in other words how big is the role of the application?
Many thanks in advance,
.peter
_______________________________________________
LARTC mailing list / LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
