Have you ever experienced "slow internet" when there is another ongoing transfer on your wire which fully saturates the bandwidth. Even if one can accept high latency of HTTP transfers (sooner or later the page will appear in the browser), in case of interactive sessions like SSH it is completely unacceptable. Wondershaper is a great remedy with minimal side effects - especially if your are running your router on Linux machine.
Wondershaper is using CBQ instead of HTB and I am aware that there are better approaches to traffic shaping in Linux. But "traffic shaping" is usually associated with the context of splitting the bandwidth of single internet link among many hosts. This is too much in my case and wondershaper does exactly what I expect.
My ADSL line is 1024/256kb officially. But in logs I can see different values:
ATM dev 0: ADSL line is up (1312 kb/s down | 320 kb/s up)
At first I tried to provide these values to wondershaper, however they were too high (high latency still and packet drops in addition). By using different values I finally established that official numbers give the best trade-off between latency and link speed.
In case of my link the average download rate is around 126KB/s. Now with wondershaper it is around 120KB/s - about 95% of the original speed - this the cost. However SSH sessions work like a charm when updates are being downloaded and the browser loads pages almost as fast as usually.
Now specific section of my
/etc/network/interfaces (Debian specific) looks like:
auto ppp0 iface ppp0 inet ppp pre-up /usr/local/sbin/firewall.sh start pre-up while ! grep 'Line up' /proc/net/atm/speedtch:0 &>/dev/null; do sleep 1; done post-up echo "1" >/proc/sys/net/ipv4/ip_forward post-up wondershaper ppp0 1024 250 pre-down wondershaper clean ppp0 pre-down echo "0" >/proc/sys/net/ipv4/ip_forward post-down /usr/local/sbin/firewall.sh stop
1024 256 values I still had some latency where my uplink was fully saturated. The
1024 250 values seems to work OK.