Date: Thu, 18 Jul 2013 16:31:10 -0600 From: John Nielsen <lists@jnielsen.net> To: Petar Bogdanovic <petar@smokva.net> Cc: freebsd-wireless@freebsd.org Subject: Re: high latency due to distant clients Message-ID: <9A1C017F-E982-4317-B92F-4B2D494A3081@jnielsen.net> In-Reply-To: <20130718171945.GA6817@pintail.NGC004> References: <20130718155200.GA381@pintail.NGC004> <CAJ-VmonT=PDLOXQpeyvCGwS3QPciUTJuB316nMAvAUzSfx7HEg@mail.gmail.com> <20130718160436.GB381@pintail.NGC004> <CAJ-VmokBOrwDF926V6jnXPCu6zbxHo1rNVddPJfLbTA-SgkFeQ@mail.gmail.com> <20130718171945.GA6817@pintail.NGC004>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 18, 2013, at 11:22 AM, Adrian Chadd <adrian@freebsd.org> wrote: > On Jul 18, 2013, at 11:19 AM, Petar Bogdanovic <petar@smokva.net> = wrote: >=20 >> 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: >>>>>=20 >>>>> I think I fixed this in -HEAD. >>>>=20 >>>> Uh-oh, great! Will that change reach a stable release anytime = soon? >>>=20 >>> When 10.0 is stable, yup. :) >>>=20 >>>> And--out of naive curiosity--what was the problem? >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>=20 >> Thanks for the nice and comprehensive explanation! >>=20 >> 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). >=20 > I really do suggest -HEAD everything. If it makes you feel any better, I've been running -HEAD (with = semi-regular updates) on my ALIX AP for a while without any trouble. Of = course, I do the builds on another box... I'm happy to share make = settings, etc if that would be useful. JN
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9A1C017F-E982-4317-B92F-4B2D494A3081>