Date: Mon, 21 Jun 2010 21:42:10 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: freebsd-ipfw@freebsd.org, Morgan Wesstr?m <freebsd-questions@pp.dyndns.biz>, freebsd-questions@freebsd.org, Modulok <modulok@gmail.com> Subject: Re: Online gaming and file downloads - latency hell! (fwd) Message-ID: <20100621212134.K9227@sola.nimnet.asn.au>
next in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1718654167-1277120478=:9227 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-ID: <20100621214150.X9227@sola.nimnet.asn.au> Hi .. as suggested, posting this discussion to ipfw@ too .. thanks, Ian ---------- Forwarded message ---------- Date: Mon, 21 Jun 2010 13:00:14 +0200 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Ian Smith <smithi@nimnet.asn.au> Subject: Re: Online gaming and file downloads - latency hell! (fwd) On Mon, Jun 21, 2010 at 10:25 AM, Ian Smith <smithi@nimnet.asn.au> wrote: > Hi Luigi, > > thought you might be interested, seeing you and ipfw+dummynet rate a > mention .. maybe I'm ill-informed about the gaming latency aspect? > > cheers, Ian for responsive flows (e.g. tcp), it is actually effective to shape incoming traffic for the flows that you want slow down. In fact, even though it is true that packets have already traversed the bottleneck, you are slowing down their arrival to the receiving TCP, which has the side effect of slowing down outgoing acks and thus slowing down the source. Queues will build up at the remote end while the system settles, but after that (and if you make sure that the total rate is lower than link capacity) it will be the sources that do not generate traffic that saturates the link. Pretty trivial to implement, too: you just need a set of rules that match the incoming traffic that you want to slow down, pass it to one pipe, and let the other traffic go through without filtering. cheers luigi > > ---------- Forwarded message ---------- > Date: Mon, 21 Jun 2010 15:50:05 +1000 (EST) > From: Ian Smith <smithi@nimnet.asn.au> > To: Morgan Wesstr?m <freebsd-questions@pp.dyndns.biz> > Cc: freebsd-questions@freebsd.org, Modulok <modulok@gmail.com> > Subject: Re: Online gaming and file downloads - latency hell! > > In freebsd-questions Digest, Vol 315, Issue 11, Message: 9 > On Fri, 18 Jun 2010 12:11:48 +0200 > Morgan Wesstr?m <freebsd-questions@pp.dyndns.biz> wrote: > > On 2010-06-16 02:51, Modulok wrote: > > > Yo, > > > > > > I have a FreeBSD box acting as a router between me and the Internet. > > > Whenever someone on the local network downloads something, the other > > > connections have a really high latency. A second or more. For people > > > who like to download large files and play online games, it's not good. > > > > > > I tried traffic shaping with PF, which works - almost: I tried the > > > home example in the PF book, but it doesn't work out so well. I can > > > throttle users with no trouble, but even so that doesn't seem to help > > > the latency issue unless I choke the 'big file download' users almost > > > completely off. It's like nothing helps. I tried a priority based > > > queue where all traffic on the gaming ports was placed in front of all > > > other traffic, and while I saw a very mild improvement, latency was > > > still really pitiful. > > > > > > Is there anything else I can do? Anyone have a similar setup and wish > > > to share config files? Are there some sysctl's that would help this > > > out or something. I'm almost ready to just buy a 'gaming' *gag* router > > > which implements their own brand of QoS, but don't want to sink to > > > that level if I don't have to. > > > > > > Help! > > > -Modulok- > > > > Traffic shaping on your side when downloading unfortunately doesn't help > > you. The data has already been transferred across your cable or DSL > > connection by then and reordering any packets on your side will not > > change the latency. Traffic shaping your download has to be performed at > > your upstream router which you probably don't control. PF can help you > > traffic shape your outgoing traffic. I have used it for this for the > > past 6 years to help me maintain a low and stable ping while I play > > online, even if I upload simultaneously. I've read about people trying > > to throttle outgoing ACKs to slow down their download but that still > > wouldn't rearrange any incoming data packets so I don't see how that > > would help. I haven't tried it myself though but neither have I read > > about anyone successfully accomplishing this. > > > > Regards > > Morgan > > A short story: > > About 15 months ago, before becoming aware that Luigi and colleagues had > been busy porting ipfw and dummynet to Linux, I was asked to implement a > shaping solution for a very limited (512/512kbps) ADSL connection for a > community radio station using a Linux firewall-in-a-box called IPCop as > router, whose shaping was based on Bert Hubert's WonderShaper script, > using Linux' tc module to prioritise and shape only outbound traffic. > > Having used ipfw+dummynet successfully for some years to shape traffic > for a local voluntary organisation 'Community Technology Centre', I was > staggered to find that all of the collective Linux wisdom on the subject > chanted that same mantra .. that you can't prioritise download traffic, > as the ISP will have 'gigantic queues' of TCP traffic that you can't > control, and that prioritising ACKs, QoS and ICMP traffic and such is > the best you can do. By this philosophy, tc only implements limiting > total bandwidth of inbound traffic, shaping outbound by QoS and classes. > > To disprove this pervasive myth I had to implement inbound shaping by > using tc to control the _outbound_ traffic to the _inside_ interface, > where all sorts of random clients are doing big downloads, yootoobing > and such plus some big uploads, while guaranteeing that the station's > outbound audio stream had fully half the outbound-to-net bandwidth free > without undue pressure and that remote ssh sessions etc remained snappy. > > This involves queuing inbound (mostly TCP) traffic on the local router, > dropping any excess, which works most effectively to maintain a hard > limit to downloads (at around 85% of 512kbps) while keeping the outbound > (to-net) channel lightly loaded after streaming, ACKs, and uploads. > > I don't know how pf works (or can be made to work) in this regard, nor > can I speculate about gaming latency particularly, but hope to find out > soon by either replacing the old IPCop box with pfSense, or trying ipfw > and dummynet on Linux .. I know, but they're still reluctant to shop > other than Linux, and the idea of implementing a FreeBSD-derived > firewall and shaping solution on Linux has a good deal of appeal .. > > HTH (or at least, doesn't hurt :) > > cheers, Ian > --0-1718654167-1277120478=:9227--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100621212134.K9227>