From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 88EFB3B2A4; Thu, 9 Feb 2017 09:45:01 -0500 (EST) Received: from mail.toke.dk (localhost.localdomain [127.0.0.1]) by mail.toke.dk (Postfix) with ESMTPS id E1B146AA34; Thu, 9 Feb 2017 15:44:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1486651499; bh=FkrIyqP2X0LfuPwgLpFLVYdfj2UVNKtFSFRu/yEh/M4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=qIUi7Hd3YNmpwR4CAF4DoOxIBOpstNYOCaf/J3udXOFeoawMR1JRHP8sbc9AdzHfq awJmAOtppFBGb0EIoPX4vwJ9j0U4GYlV7cRHCPCF4C08NEFq/i8BL5V4nDX04A4dUs Ag4WdfmTf+8j/qWXEcgs2rSM6+MTaqmQ0xR1ekeOimOzs0D7j9oxYFhVqC0ojy+qb8 /iteTvYtOMilIIVrm6f6JdCzxlmt4+dF3TzRdLlWEHtekMpa1hjI02g/oCAC/PHtC+ vpT9ALmNwY0V2ePexbpreNoFkGhdmQFZrjxD2iOXmReHfOqIHo9GPFHzCePynpZLbe UWMDOSBoFfqZg== Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 80536193FF; Thu, 9 Feb 2017 15:44:58 +0100 (CET) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Pete Heist Cc: make-wifi-fast@lists.bufferbloat.net, cake@lists.bufferbloat.net References: <32C42951-373F-4D90-8936-AA07039E5D73@gmail.com> <877f5c2pew.fsf@toke.dk> <878tpqge5g.fsf@toke.dk> <877f52rz68.fsf@toke.dk> <87bmucu0gs.fsf@toke.dk> <87y3xfsc93.fsf@toke.dk> <5700DFDD-C5C6-482E-A89C-2DB052DA61F0@gmail.com> Date: Thu, 09 Feb 2017 15:44:58 +0100 In-Reply-To: <5700DFDD-C5C6-482E-A89C-2DB052DA61F0@gmail.com> (Pete Heist's message of "Thu, 9 Feb 2017 15:20:21 +0100") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87r337s9sl.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] Flent results for point-to-point Wi-Fi on LEDE/OM2P-HS available X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 14:45:06 -0000 Pete Heist writes: > On Feb 9, 2017, at 2:51 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Also, could the queue management code be abstracted into a separate > module, so it can be replaced, like a qdisc? I don=E2=80=99t know if the > disparity between hardware makes this too difficult or not=E2=80=A6 > > Well it's abstracted into mac80211 so all wireless drivers can use it > (theoretically; right now only ath9k, ath10k and the not-yet-merged mt76 > do). Making it more generic than that is not possible, since it's tied > to the mac80211 data structures. Which is kinda the point; the whole > problem was that a "generic layer" (the qdisc) didn't work well > enough... > > Nice. :) > > I=E2=80=99ll mention one example I noticed of the kind of adjustment that > probably can=E2=80=99t be done from the qdisc layer today. On page 3 from > http://pollere.net/Pdfdocs/noteburstymacs.pdf: > > "In addition to increasing the interval by the waiting delay s, > another adjustment might be useful for certain kinds of bursty MACs. > If the MAC is a request-and-grant type, as wifi in infrastructure > mode, cable modems and some satellite modems, the allocation of bytes > or packets that can be sent during each transmission slot is generally > known at the beginning of transmission and may vary for each > transmission slot. In that case, it MAY be useful to use that value > instead of the MTU value to reset first_above_time_." Yeah, we've had this issue with CoDel when the per-station WiFi rate drops too low (this is a function of both signal quality and number of stations). As a temporary fix, I just fiddled with the target until CoDel stopped being too aggressive, but that is not a proper solution, and so has not been upstreamed. I'm planning to get back around to fixing that properly at some point... Problem is that it is not always the case that "the allocation of bytes or packets that can be sent during each transmission slot is generally known". For ath9k we could get at this information at dequeue time, but for ath10k, only the firmware knows ahead of time... -Toke