From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A92FC3B29E for ; Wed, 22 Nov 2017 11:11:03 -0500 (EST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1511367061; bh=H9wd4PzmxIIYaFrLqlhOPKzXRd3c3em3ztXVpGD18dU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=SyFpDqhhAvGagoc2UqcVJnne201ASccFPlIQmYcnb/WYzrjXaor0H2DbRmnjez+wP ag6Yeu0h1hJYj9z5asGm7I5M7yfJuRZKWDXE3ZG5NtrpPjSmE0+6bl7leC8Ds9UnBF J5lyrWRb+z/6VemzyoAKbmW0K7CgH71H+Jdz8yZmSf/ZZrSBaaK8xrn7Asc3k1Yoz3 Jtj7rZH+707nsyvdtXHscO2byC3jmpniK9pHnIWV+5Bczm2m7cmpsbki6auEgr/rAi 3ZE34/jTu4Q2dwpkf99JuAe4OaXP9Ra65E6YwSBXvWPe0El529s/bJE4H9M9DvpSnd 56sVF/Wexou7Q== To: Louie Lu Cc: Make-wifi-fast@lists.bufferbloat.net In-Reply-To: References: <87vai28k6j.fsf@toke.dk> Date: Wed, 22 Nov 2017 17:10:59 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87po8a8fak.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] How to figure out Linux wifi queue and ath10k queue scheduling? 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: Wed, 22 Nov 2017 16:11:04 -0000 Louie Lu writes: > 2017-11-22 22:25 GMT+08:00 Toke H=C3=B8iland-J=C3=B8rgensen : >> Hi Louie >> >>> I'm working on making VoWIFI performance more better on ath10k driver, >>> my first thought is that I can modify queue scheduling algorithm >>> inside ath10k. >> >> Sounds awesome! What kind of VoIP traffic are you working with, and what >> aspect of performance are you looking to improve? :) > > We are working on 802.11ac with telecom operator's VoWIFI (through > ePDG), Ah, right, so this is the same technology as VoLTE, but offloaded to WiFi? Is that a weird proprietary protocol, or is it similar to standard ones like RTP? > but much more focus on the phone to AP jitter, latency and TXOP when > AP has multiple stations (10+) traffic. Right. Well, with the 802.11 MAC there's only so much you can do about that (since there's no central controller); especially jitter is probably hard to kill entirely. What bounds on latency and jitter are you targeting? >>> After tracking the commit log, it seems currently ath10k is using >>> mac80211 as an intermidieate queue[1][2], and as [2] indicate, ath10k >>> is not able to do airtime fairness now. >> >> Yup, that's about right. We're working on the airtime fairness part, >> though; see my recent presentation at Netdev a few weeks ago for an >> updated status on previous and ongoing work [1]. > > Thanks for the update, I'll take a look at this. Also, is "airetime > fairness" a concept as fair TXOP to each station? I'm not sure if I > get this right. By "airtime fairness" we simply mean a network state where each station gets the same total amount of transmission time (as opposed to the default 802.11 behaviour which gives "throughput fairness", where slow stations take up more airtime than fast stations, slowing the whole network down). This is explained in detail in section 2.2 of the paper you already found on arxiv (the final version is published in USENIX ATC[1]; I don't recall if that is one of the sections we updated). This general behaviour of the 802.11 MAC was first described way back in 2001 and is referred to as the "performance anomaly"[2]. Since there's no central scheduling in 802.11, the way we implement airtime fairness is basically by throttling stations that take up too much airtime. This is fairly straight forward to do in the AP->station direction, since the AP controls transmissions. In the other direction there is no direct control, but by counting the receive airtime towards that station and then throttling its traffic from the AP. This works because most traffic is TCP. Currently, throttling takes place after the fact (i.e., we don't adjust the length of the transmissions). The idea of making TXOPs smaller as the number of stations goes up has been discussed on this list before (and is mentioned on slide 15 of the talk I linked to before), but we haven't gotten around to implementing it yet. And since ath10k does aggregation and rate control in firmware, I'm not sure if it's possible to do at the driver level there... >> The work on the different QoS levels has mostly been on the idea stage >> so far. My presentation[1] has some ideas related to this as well, but >> nothing has been implemented thus far. What's on the roadmap depends >> mostly on what people go ahead and implement ;) > > Got it, but are there any udpate about the make-wifi-fast google docs? > Or this is the latest version of it. Beside patchwork, is there an > issue tracker or just mailing list to get the latest information? Not really, no. You've already found the mailing list; most things take place here (and on linux-wireless, but I at least try to CC both lists in the stuff I post). Looking through the mailing list archive can be a source of ideas, or just posting and soliciting feedback :) -Toke [1] https://www.usenix.org/conference/atc17/technical-sessions/presentation= /hoilan-jorgesen [2] http://ieeexplore.ieee.org/abstract/document/1208921/?reload=3Dtrue