I'm trying to create a relatively simple traffic shaping environment; basically, we're a home network with three different classes of traffic:
1) High-priority, which means usually low bandwidth but very demanding latency requirements. In English: online gaming. :) 2) Medium-priority, which includes most of what people think of as "normal" Internet traffic. Web browsing, email, USENET, IRC, etc. 3) Low-priority, which includes bulk traffic like big file downloads.
Basically, the cake that I'm trying to have and eat it too is where we can be running a bunch of stuff like BitTorrent clients to download new Quake maps, and still be playing Battlefield 1942 without getting hammered on by the P2P clients' data transfers and node-building traffic.
Bittorrent is the hardest thing I've tried to shape yet. It uses 20+ full duplex tcp and your peers may well have a 2 sec flooded buffer. This means that if you use it alot you would be best to get it in it's own class and set, say max 60% down - and down is the problem, you have total control over upstream so that is sortable.
This is what I have so far; it has made a definite improvement for "prio 1 traffic" (the medium stuff, web browsing and such) but doesn't seem to be enough; online gaming is still quite laggy while the file transfers and such are active. At this point it seems that what I basically need to do is tweak the values of the $UPSTREAM_* variables, but I thought I might ask here first to see if there's an entire design-level improvement to be made. The basic idea is that "medium" traffic should be able to stomp on "low" traffic (represented by the default case) when it needs bandwidth/latency, and that "high" traffic should be able to stomp on both "medium" and "low" when it needs bandwidth/latency...but the lower classes can borrow bandwidth when the classes that outrank them aren't using it.
This is sort of what I am doing (though what I do keeps changing).
TCP slowstart is a pain - It's hard not to get a latency blip, when new connections start - but they don't last that long.
From reading the parts of the HOWTO that I could get my mind around, I understand that only outbound traffic can be molded, so the script below makes no attempt to do anything with inbound traffic.
You can and need to shape downstream - it's not actually possible to do it perfectly with the TC stuff, but you can make it alot better than doing nothing. It involves sacrificing some 20-40% of your bandwidth - depending on how many active tcp connections and how much you care about latency.
How you do it exactly depends on your setup - there is an example of using the basic ingress policer in the wonder shaper script. It is better to shape using htb & queues on your LAN facing interface if possible, you can also use IMQ. For ingress I find esfq is better than sfq as you can limit the queue length. I am still experementing with my home setup and have modified the hash for ingress and made it head drop, which seem to help a bit - but I haven't tested enough to see if it's now broken in any way.
In a tangentally-related question, I'm having some trouble determining what number I should put for $UPSTREAM_TOTAL. I sort of arrived at 15 by trial and error -- but if anybody has any suggestions on ways to empirically determine what your upload speed actually is, they would be most welcome. :)
Most people know what their bandwidth is :-) However If you have dsl and it's sold as 128kbit/s up then 15KB is probably too high - there is alot of overhead and while htb calculates an empty ack as 40 bytes, it actually uses 106 on a dsl wire. I throttle to 85% upstream - could go higher I guess, but remember that while a bulk upload may be OK at say 90%, 30 small game packets/sec will be miscalculated more % than bigger packets.
Another tweak which helped me, was changing a setting in htb, before I did this I found that packets were being sent in pairs.
set HTB_HYSTERESIS 0 in net/sched/sch_htb.c
Oh, one other thing...does "u32 match ip [sd]port N" match both TCP and UDP port N, or just TCP? I'm wondering if that may be part of the problem, since most online games use UDP for the client connections.
Thanks to anyone who takes a look; let me know if there's any more information from our configuration/setup that would be helpful.
I can't help you there - I mark with iptables and filter on the marks.
Andy.
_______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
