Played a bit with traffic shaping over the weekend. I'm on a cable modem, and without shaping frames go out of my computer at 10Mbit/s and get buffered into the cable modem before they get to the 128Kbit/s uplink, which results in very bad lag whenever I upload anything.

I had never played with this before, and I was amazed how much it helps. Now my telnets never get lagged at all, and the reduced latency also seems to help when I do some downloads. If people are interested, I would recommand them to use:

"tbf" for the basic shaping - making sure we do not overfill the modem's internal buffers. I did that with "tc qdisc add dev eth0 root handle 1: tbf rate 120kbit burst 2000 mpu 128 limit 100000". I would recommend people to use the tbf patch from http://luxik.cdi.cz/~devik/qos/qos.htm - it allows you to put additional shaping disciplines "inside" of the tbf shaper. (I dont know if its still required if you run 2.4 - I'm still running a 2.2 kernel)

"prio" works good enough to do the prioritization, based on the Type Of Service field of the IP headers. Most linux applications set it correctly, so you dont have to scratch your head too hard to prioritize your packets. If I was doing a gateway for windows machines I guess my life would be harder though. For now, I just did "tc qdisc add dev eth0 parent 1:1 handle 2: prio". interactive traffic (telnet, ssh) is prioritized over control traffic (dns, ping, netscape apparently ends up there too), and the lowest priority is bulk data (wget, scp, ftp, fetchmail, ...)

"sfq" tries to make the shaping more fair - so that if in the same priority band you transfer files to different places at the same time, they will get roughly equivalent amounts of bandwidth, even if one is far away with more ping delay and stuff. So I added it in all three priority bands: "tc qdisc add dev eth0 parent 2:1 handle 10: sfq perturb 600", "tc qdisc add dev eth0 parent 2:2 handle 20: sfq perturb 600" and "tc qdisc add dev eth0 parent 2:3 handle 30: sfq perturb 600". The perturb parameter is there to work around some limitations in the sfq algorithm, I found out that lower values (10 or so) tend to slow down the transfers a bit as they make packets appear out of order at times and that confuses the TCP bandwidth management algorithms.

Now the funny thing is, that I was only doing this to get me started - my longer term project was to set up shaping on downloads, which seems to be harder to do with the current linux code. AT&T cable had that very nasty capping to 1.5 mbit/s, which was done with a 1-second granularity: you could download 160KB or so, which for a close server took about half a second, then things would freeze for half a second, then it would start again, etc... that was pretty bad if you had connections to a remote server at the same time - these would usualy timeout because of loosing half of their packets. So, I was just getting ready to fight that by doing shaping on my end at a lower speed, say 1.4 mbit/s or so - but, AT&T beat me to it, and they fixed the problems on their end ! Incredible, they made me a happy guy. So, now I get smooth transfers in both directions and no delays. I guess I never liked cable so much before :)