Re: [LARTC] Basic HTB shaping configuration

[Andy Furniss <andy.furniss@dsl.pipex.com>]

John Buttery wrote:
>   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@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/