Date: Thu, 18 Jul 2013 19:19:45 +0200 From: Petar Bogdanovic <petar@smokva.net> To: freebsd-wireless@freebsd.org Subject: Re: high latency due to distant clients Message-ID: <20130718171945.GA6817@pintail.NGC004> In-Reply-To: <CAJ-VmokBOrwDF926V6jnXPCu6zbxHo1rNVddPJfLbTA-SgkFeQ@mail.gmail.com> References: <20130718155200.GA381@pintail.NGC004> <CAJ-VmonT=PDLOXQpeyvCGwS3QPciUTJuB316nMAvAUzSfx7HEg@mail.gmail.com> <20130718160436.GB381@pintail.NGC004> <CAJ-VmokBOrwDF926V6jnXPCu6zbxHo1rNVddPJfLbTA-SgkFeQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 18, 2013 at 09:25:19AM -0700, Adrian Chadd wrote: > On 18 July 2013 09:04, Petar Bogdanovic <petar@smokva.net> wrote: > > On Thu, Jul 18, 2013 at 08:59:29AM -0700, Adrian Chadd wrote: > >> > >> I think I fixed this in -HEAD. > > > > Uh-oh, great! Will that change reach a stable release anytime soon? > > When 10.0 is stable, yup. :) > > > And--out of naive curiosity--what was the problem? > > The ath driver before 11n support went in would just fill the hardware > TX queue with frames. There's no per-station queue or any kind of fair > queuing. So if you fill the TX queue in the driver with frames to a > far away station, it'll block all frames to other stations whilst > they're transmitted and retransmitted. > > When I introduced 11n support, I added per-station and > per-traffic-class queues in the driver as part of A-MPDU support. I > software queue almost everything first and then schedule frames to the > hardware from these software queued frames. This has the side effect > of making it fairer between multiple stations, especially if one of > them is far away. It will only schedule a small number of frames to > each station before going to another station, rather than possibly > being backed up with 128 frames just to a single destination. > > Now, it's likely there's more work that can be done to improve that > behaviour with slow, far away clients. The framework is there in > -HEAD. I've just not sat down and made it work. So if you update to > -HEAD and you still have problems, we can tweak things and experiment. Thanks for the nice and comprehensive explanation! I'll prepare the upgrade during the next couple of weeks and report back. It will probably be 9.1 userland and HEAD kernel (that approach worked well in the past). Petar Bogdanovic
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130718171945.GA6817>