From owner-freebsd-wireless@FreeBSD.ORG Thu Jul 18 16:25:21 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 86C54CD for ; Thu, 18 Jul 2013 16:25:21 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 23A73995 for ; Thu, 18 Jul 2013 16:25:20 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id w57so3139452wes.29 for ; Thu, 18 Jul 2013 09:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=F7N+IkLJqr/gJUU0kvPZKkzuIis3HwSWGO6CiAz5UfU=; b=LgT5cynXtb4d3GPDSl4WgYCrTBCsQqPIsgrYo/NbXsGbU+NJdS6HhPVG3ZOMv0mBrW +emheGY0ftkTfXZbGKSZ/pyEOZdAqHJysBBVxMPrPHhF44H1z3WQYaT0KstjBejpdXTL Arq9pBwChD/ROUF+PyJOlxm8mBaSxLTK8XHsIh754/tHv3YHekE/K7Mv9O6lp64pkB7Z 4PU3wTYz88yEhrKwMTMKsNdfjeOLpBXqNx+2+0L12szbkiViru3XlU+ENFiKyiRmKVvu Xp5QhYjKf9pvPgamj9YbhFdeE6DSXTjDYaeyfUdNXtD/uaCV8vCeE7044Y3oKvrWTRxc YZ8Q== MIME-Version: 1.0 X-Received: by 10.180.160.165 with SMTP id xl5mr19816951wib.46.1374164719417; Thu, 18 Jul 2013 09:25:19 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Thu, 18 Jul 2013 09:25:19 -0700 (PDT) In-Reply-To: <20130718160436.GB381@pintail.NGC004> References: <20130718155200.GA381@pintail.NGC004> <20130718160436.GB381@pintail.NGC004> Date: Thu, 18 Jul 2013 09:25:19 -0700 X-Google-Sender-Auth: U_RbhaTLaPOpcQx9JqGexv_SeqA Message-ID: Subject: Re: high latency due to distant clients From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 16:25:21 -0000 On 18 July 2013 09:04, Petar Bogdanovic 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.