From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from smtp.codeaurora.org ([198.145.29.96]) by bombadil.infradead.org with esmtps (Exim 4.92.2 #3 (Red Hat Linux)) id 1iCg5s-0005En-V6 for ath10k@lists.infradead.org; Tue, 24 Sep 2019 08:22:46 +0000 MIME-Version: 1.0 Date: Tue, 24 Sep 2019 16:22:43 +0800 From: Yibo Zhao Subject: Re: [PATCH V3 3/4] mac80211: fix low throughput in multi-clients situation In-Reply-To: <87impj5lkm.fsf@toke.dk> References: <1569223201-1490-1-git-send-email-yiboz@codeaurora.org> <1569223201-1490-4-git-send-email-yiboz@codeaurora.org> <87impj5lkm.fsf@toke.dk> Message-ID: <2aab0bd944ee34751304a5f92b885113@codeaurora.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: "ath10k" Errors-To: ath10k-bounces+kvalo=adurom.com@lists.infradead.org To: =?UTF-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= Cc: linux-wireless-owner@vger.kernel.org, linux-wireless@vger.kernel.org, ath10k@lists.infradead.org T24gMjAxOS0wOS0yMyAxODo1NSwgVG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2VuIHdyb3RlOgo+IFlp Ym8gWmhhbyA8eWlib3pAY29kZWF1cm9yYS5vcmc+IHdyaXRlczoKPiAKPj4gTm90IGxvbmcgYWZ0 ZXIgdGhlIHN0YXJ0IG9mIG11bHRpLWNsaWVudHMgdGVzdCwgbm90IGEgc2luZ2xlIHN0YXRpb24g Cj4+IGlzCj4+IGFuIGVsaWdpYmxlIGNhbmRpZGF0ZSBmb3IgdHJhbnNtaXNzaW9uIHNpbmNlIGds b2JhbCB2aXJ0dWFsIHRpbWUoZ192dCkgCj4+IGlzCj4+IHNtYWxsZXIgdGhhbiB0aGUgdmlydHVh bCBhaXJ0aW1lKHNfdnQpIG9mIGFsbCB0aGUgc3RhdGlvbnMuIEFzIGEgCj4+IHJlc3VsdCwKPj4g dGhlIFR4IGhhcyBiZWVuIGJsb2NrZWQgYW5kIHRocm91Z2hwdXQgaXMgcXVpdGUgbG93Lgo+PiAK Pj4gVGhpcyBtYXkgbWFpbmx5IGR1ZSB0byBzeW5jIG1lY2hhbmlzbSBhbmQgYWNjdW11bGF0aXZl IGRldmlhdGlvbiBmcm9tIAo+PiB0aGUKPj4gZGV2aXNpb24gY2FsY3VsYXRpb24gb2YgZ192dC4K Pj4gCj4+IEZvciBleGFtcGxlOgo+PiBTdXBwb3NlIHdlIGhhdmUgNTAgY2xpZW50cyBpbiBmaXJz dCByb3VuZC4KPj4gUm91bmQgMToKPj4gU1RBCXdlaWdodAlUeF90aW1lX3JvdW5kICB3dF9zdW0J c192dAlnX3Z0ICB2YWxpZF9mb3JfbmV4dF9UeAo+PiAxCTI1NgkyMDQ4CQkxMjgwMAkyMDQ4CTIw MDAJTgo+PiAyCTI1NgkyMDQ4CQkJMjA0OAkJTgo+PiAuCS4JLgkJCS4JCS4KPj4gLgkuCS4JCQku CQkuCj4+IC4JLgkuCQkJLgkJLgo+PiA1MAkyNTYJMjA0OAkJCTIwNDgJCU4KPj4gCj4+IEFmdGVy IHRoaXMgcm91bmQsIGFsbCB0aGUgc3RhdGlvbnMgYXJlIG5vdCB2YWxpZCBmb3IgbmV4dCB0cmFu c21pc3Npb24gCj4+IGR1ZSB0bwo+PiBhY2N1bXVsYXRpdmUgZGV2aWF0aW9uLgo+PiAKPj4gQW5k IGlmIHdlIGFkZCBhIG5ldyAjNTEsCj4+IFNUQQl3ZWlnaHQJVHhfdGltZV9yb3VuZCAgd3Rfc3Vt CXNfdnQJZ192dCAgdmFsaWRfZm9yX25leHRfVHgKPj4gMQkyNTYJMjA0OAkJMTMwNTYJMjA0OAky MDIwCU4KPj4gMgkyNTYJMjA0OAkJCTIwNDgJCU4KPj4gLgkuCS4JCQkuCj4+IC4JLgkuCQkJLgo+ PiAuCS4JLgkJCS4KPj4gNTAJMjU2CTIwNDgJCQkyMDQ4CQlOCj4+IDUxCTI1NgkxMDI0CQkJMjUy NAkJTgo+IAo+IFRoYXQncyBiZXR0ZXIgOikKPiAKPj4gU3luYyBpcyBkb25lIGJ5Ogo+PiBtYXgo Z192dCBvZiBsYXN0IHJvdW5kIC0gZ3JhY2UgcGVyaW9kLCBzX3Z0KQo+PiBhbmQgc192dCBvZiAj NTEgPSBtYXgoMjAwMCAtIDUwMCwgMCkgKyAxMDI0ID0gMjUyNCwgYW5kIGl0IGlzIG1vcmUgCj4+ IHRoYW4gdGhlIGZpbmFsCj4+IGdfdnQgb2YgdGhpcyByb3VuZC4KPj4gCj4+IEFmdGVyIHRoaXMg cm91bmQsIG5vIG1vcmUgc3RhdGlvbiBpcyB2YWxpZCBmb3IgdHJhbnNtaXNzaW9uLgo+PiAKPj4g VGhlIHJlYWwgc2l0dWF0aW9uIGNhbiBiZSBtb3JlIGNvbXBsaWNhdGUsIGFib3ZlIGlzIG9uZSBv ZiB0aGUgCj4+IGV4dHJlbWVseSBjYXNlLgo+PiAKPj4gVG8gYXZvaWQgdGhpcyBzaXR1YXRpb24g dG8gb2NjdXIsIHRoZSBuZXcgcHJvcG9zYWwgaXM6Cj4+IAo+PiAtIEluY3JlYXNlIHRoZSBhaXJ0 aW1lIGdyYWNlIHBlcmlvZCBhIGxpdHRsZSBtb3JlIHRvIHJlZHVjZSB0aGUKPj4gICB1bmV4cGVj dGVkIHN5bmMKPj4gCj4+IC0gSWYgZ2xvYmFsIHZpcnR1YWwgdGltZSBpcyBsZXNzIHRoYW4gdGhl IHZpcnR1YWwgYWlydGltZSBvZiBhbnkgCj4+IHN0YXRpb24sCj4+ICAgc3luYyBpdCB0byB0aGUg YWlydGltZSBvZiBmaXJzdCBzdGF0aW9uIGluIHRoZSByZWQtYmxhY2sgdHJlZQo+PiAKPj4gLSBS b3VuZCB0aGUgZGl2aXNpb24gcmVzdWx0Cj4gCj4gSSBjYW4gc2VlIHdoeSB3ZSBuZWVkIHRoZSBz ZWNvbmQgcGFydCAoYmFzaWNhbGx5LCB0aGlzIGhhcHBlbnMgYmVjYXVzZSAKPiBJCj4gZm9yZ290 IHRvIGFkZCBhIGNoZWNrIGZvciAibm8gZWxpZ2libGUgc3RhdGlvbnMiIGluIG1heV90cmFuc21p dCgpLCAKPiBsaWtlCj4gdGhlIG9uZSBpbiBuZXh0X3R4cSgpKS4gQW5kIHJvdW5kaW5nIHVwIHRo ZSBkaXZpc2lvbiByZXN1bHQgZG9lc24ndAo+IGh1cnQsIEkgZ3Vlc3MuIEJ1dCB3aHkgZG9lcyBp dCBoZWxwIHRvIGNoYW5nZSB0aGUgZ3JhY2UgcGVyaW9kIGlmIHdlJ3JlCj4gZG9pbmcgYWxsIHRo ZSBvdGhlciBzdHVmZj8KSW4gbXVsdGktY2xpZW50cyBjYXNlLCBpdCBpcyBwb3NzaWJsZSBhIFRY USBzb21ldGltZXMgZ2V0cyBkcmFpbmVkIGR1ZSAKdG8gRlcgaGFzIGRlZXAgcXVldWUgYW5kIGZl dyBwYWNrZXRzIGluIFRYUSBhdCB0aGF0IHRpbWUuIFNvIHRoZSBUWFEgaXMgCnJlbW92ZWQgZnJv bSB0aGUgcmJ0cmVlIGFmdGVyIGRlcXVldWluZy4gV2hlbiBpdCBpcyBhYm91dCB0byBhZGRlZCBi YWNrIAp2ZXJ5IHNvb24gYWZ0ZXIgdGhlIHJlbW92YWwsIHRoZSBnX3Z0IG1pZ2h0IGhhdmUgZ29u ZSBhIGxpdHRsZSBmYXIgYXdheSAKZnJvbSBzdGEgdnQgd2hlcmUgc3luYyBpcyBuZWVkZWQuIFdp dGggdGhpcyBzeW5jLCB0aGUgc3RhdGlvbiBpcyBmb3JjZWQgCnRvIGNhdGNoIHVwIHdpdGggdGhl IGdfdnQsIGhvd2V2ZXIsIGl0cyBjaGFuY2UgZm9yIHRyYW5zbWlzc2lvbiBoYXMgYmVlbiAKcmVk dWNlZC4gSSB0aGluayA1MDB1cyBpcyBxdWl0ZSBhIHNob3J0IHBlcmlvZCBpbiBtdWx0aS1jbGll bnRzIGNhc2UuCj4gCj4gLVRva2UKCi0tIApZaWJvCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwphdGgxMGsgbWFpbGluZyBsaXN0CmF0aDEwa0BsaXN0cy5p bmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8v YXRoMTBrCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0BAC8C432C1 for ; Tue, 24 Sep 2019 08:22:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D33C020872 for ; Tue, 24 Sep 2019 08:22:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=codeaurora.org header.i=@codeaurora.org header.b="JoFZ3bv0"; dkim=fail reason="key not found in DNS" (0-bit key) header.d=codeaurora.org header.i=@codeaurora.org header.b="Dd9HOt1n" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2409448AbfIXIWq (ORCPT ); Tue, 24 Sep 2019 04:22:46 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:36762 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2409445AbfIXIWp (ORCPT ); Tue, 24 Sep 2019 04:22:45 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 5886B602F2; Tue, 24 Sep 2019 08:22:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1569313364; bh=32NmNmKKduEVdtULZjfuI+1nlnbYAGk25UhmZpR6+74=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=JoFZ3bv06iThmtbrQ24T6AZyC7WYie0uxNAikBSG6CeQFHhWaDh1qlbYq8cMOF3lL A1zDQ4MWFGwNxXoItlrjYXgaB28hmkoqJunQkdm8eU4gb4CD+vUNe9Rkp8Vpuvp8iT P3Lt3TbTUmss+xHx/ELdBnfuluh+C+FBh+1/0Ues= Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 92DEE601D4; Tue, 24 Sep 2019 08:22:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1569313363; bh=32NmNmKKduEVdtULZjfuI+1nlnbYAGk25UhmZpR6+74=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Dd9HOt1ntIEFGIccv3r62hjZeD2S0Z0kqnyKFeOYnHGqoijNhrALiUciaxN1bk4wI EHLR0QPUfMu5j/EeetpECV3zmyLMHvk8Ncru1esQv8N8X5eAYPGQLPi4C+q/v/gqrg YSSd4ntmxdd4/epjjHBcCokzBL1c9+ou4BnTyDk0= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 24 Sep 2019 16:22:43 +0800 From: Yibo Zhao To: =?UTF-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org, linux-wireless-owner@vger.kernel.org Subject: Re: [PATCH V3 3/4] mac80211: fix low throughput in multi-clients situation In-Reply-To: <87impj5lkm.fsf@toke.dk> References: <1569223201-1490-1-git-send-email-yiboz@codeaurora.org> <1569223201-1490-4-git-send-email-yiboz@codeaurora.org> <87impj5lkm.fsf@toke.dk> Message-ID: <2aab0bd944ee34751304a5f92b885113@codeaurora.org> X-Sender: yiboz@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On 2019-09-23 18:55, Toke Høiland-Jørgensen wrote: > Yibo Zhao writes: > >> Not long after the start of multi-clients test, not a single station >> is >> an eligible candidate for transmission since global virtual time(g_vt) >> is >> smaller than the virtual airtime(s_vt) of all the stations. As a >> result, >> the Tx has been blocked and throughput is quite low. >> >> This may mainly due to sync mechanism and accumulative deviation from >> the >> devision calculation of g_vt. >> >> For example: >> Suppose we have 50 clients in first round. >> Round 1: >> STA weight Tx_time_round wt_sum s_vt g_vt valid_for_next_Tx >> 1 256 2048 12800 2048 2000 N >> 2 256 2048 2048 N >> . . . . . >> . . . . . >> . . . . . >> 50 256 2048 2048 N >> >> After this round, all the stations are not valid for next transmission >> due to >> accumulative deviation. >> >> And if we add a new #51, >> STA weight Tx_time_round wt_sum s_vt g_vt valid_for_next_Tx >> 1 256 2048 13056 2048 2020 N >> 2 256 2048 2048 N >> . . . . >> . . . . >> . . . . >> 50 256 2048 2048 N >> 51 256 1024 2524 N > > That's better :) > >> Sync is done by: >> max(g_vt of last round - grace period, s_vt) >> and s_vt of #51 = max(2000 - 500, 0) + 1024 = 2524, and it is more >> than the final >> g_vt of this round. >> >> After this round, no more station is valid for transmission. >> >> The real situation can be more complicate, above is one of the >> extremely case. >> >> To avoid this situation to occur, the new proposal is: >> >> - Increase the airtime grace period a little more to reduce the >> unexpected sync >> >> - If global virtual time is less than the virtual airtime of any >> station, >> sync it to the airtime of first station in the red-black tree >> >> - Round the division result > > I can see why we need the second part (basically, this happens because > I > forgot to add a check for "no eligible stations" in may_transmit(), > like > the one in next_txq()). And rounding up the division result doesn't > hurt, I guess. But why does it help to change the grace period if we're > doing all the other stuff? In multi-clients case, it is possible a TXQ sometimes gets drained due to FW has deep queue and few packets in TXQ at that time. So the TXQ is removed from the rbtree after dequeuing. When it is about to added back very soon after the removal, the g_vt might have gone a little far away from sta vt where sync is needed. With this sync, the station is forced to catch up with the g_vt, however, its chance for transmission has been reduced. I think 500us is quite a short period in multi-clients case. > > -Toke -- Yibo