Re: [LARTC] Latency low enough for gaming

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

Patrick Petersen wrote:
> Welcome to me, and my very first lartc post.
> As with most first timers, i made a mistake. Admin, disregard the
> earlier message, as i was still waiting for the subscription
> confirmation. Should it get through still, i apoligize.
> 
> For the last few weeks i have been trying to make it so our 2048/512
> adsl line can be used for gaming and for leeching at the same time. The
> current result is what can be found at http://www.schmakk.dk/~schmakk
> which is what is running at the NAT gateway. This has done a lot for the
> latency, but still there is huge problems with eg. massive http
> downloads (5+ threads makes ping go up to at least 200).
> 
> I have learned a lot from the lartc list archive, but this specifik
> leaves me with no clue. I have been able to get real close to normal
> latency by capping incoming traffic at around 1200kbits, but its no fun
> throwing away almost half your bandwidth.
> 
> Can i get any recommendations?
> 
> Also, if you have the time, a look through my script is much appreciated.
> (Im concerned about the calculations for dividing the bandwidth, the
> general setup of everything and the ipp2p+connmark tagging.)

I see you have a newer version now anyway, but I tried you script last 
night (not connmark/ipp2p as it clashed with connbytes). I have 256/512 
so things in theory should be nicer for you.

I am still testing myself, so can't post a solution but can make some 
observations -

The delete rule for iptabled needs -D not -A.

esfq won't work hashing src on egress if you are doing NAT see the KPTD 
on www.docum.org - egress qos comes after NAT. Ingress with dst should 
be ok if you are NATing as long as you used the IMQ NAT patch.

The trouble with esfq hashing per user (unless you use limit) is that 
each user gets a 128 packet queue, which if they have many connections 
gets full and drops take a long time to be noticed. I have a modified 
esfq which overcomes this somewhat, but I also use classic hash and 
restrict the size of the queue.

I can see why commercial bandwidth controllers use advertised window 
manipulation - often dropping is needed to get the sender to back off a 
bit and set its' congestion window, but if you queue this may result in 
a resync burst later. Being able to reduce adv window on dups/sacks and 
increase slowly/randomly would be handy.

One thing that helps me is to give new bulk connections their own class 
with a short queue for the first 80000 bytes using connbytes (netfilter 
extra patch). This is limited to rate downrate/5 ceil /3 and stops tcp 
slowstart from overshooting. I have also tried connbytes just to drop 
early packets, but with browsers making many simultaneous connections, 
the resyncs cause a latency burst.

I see you are trying RED - in theory this should be nice, but remember 
the settings/docs you read about don't take into account that you are 
trying to shape behind a fifo (at ISP/teleco) that dequeues only 20% 
faster than what you are aiming for.

I am not convinced that just dropping ingress is best - a short queue 
yes, then at least you don't ever drop game packets.

If I had 2048 down I reckon I could keep down below 100 now - apart from 
the odd 1 sec blip.

Andy.

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/