From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 454DD3B2A4 for ; Tue, 16 Jun 2020 07:50:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1592308250; bh=unqzD/4+xTv5ygrdkb5KE8nFFZU78z+smlUx4I1NEpc=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=KMzBx9xxO8/bTaeIM6cdTcWITd1oou407blAGKezwK8NBk62pF19BLlz6/ZIf6odY n8ODf5HY2fn/ax4Wm6VPMCRS7pgk0TsozS2c5IvrEOpb4rVp8zBNq5QncuObgFSWr7 hEAe9h919LY0pVFislGbzSjERuH/BgVZ26rF7Gs8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.11.12.3] ([134.76.241.253]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Msq6M-1is6eQ1Dlw-00tBeF; Tue, 16 Jun 2020 13:50:50 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Sebastian Moeller In-Reply-To: <87sgevz1iu.fsf@toke.dk> Date: Tue, 16 Jun 2020 13:50:49 +0200 Cc: Michael Yartys , Michael Yartys via Make-wifi-fast Content-Transfer-Encoding: quoted-printable Message-Id: <709555FC-4203-486B-8B40-86FAD9F0294C@gmx.de> References: <87sgevz1iu.fsf@toke.dk> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3445.104.14) X-Provags-ID: V03:K1:BJFWgPYuD2VgyXXYEJkQr1jZHRV12faQxr1YN2auj2PA913GCaU JbaX8l64x5WxBCLgKFD7P5o+pqwnvYDVwpdm88/+d32wcRGqvPb6r+1JashbDE3dQ+l85Rx 8uQa0pV1htCSfInMY7As0nVizHJkQxajwqYx9Bz+mYiy8LbbMFcTnwUy7pxZPjTplOyr2Nx biPYA4+TFyyYrUitDJv9g== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:YN2RCGgXqYU=:uuCGhB74RoYo27O1wMPWB7 2gvqzJpNYFdiaYgKR5jODZOx9aqoefeqgBmIY1/whF9rpVu/k1CH8AIVA+BSXhM2XHyZJR55o GScFECUPeKiv5EjRcsxI5jVBX07UYn3T6lUnGKuclYqtpEIHtMI8Kl17ogHR9prUOWhC39dyT H2cPa7B0hJik22Hpc7fiuAXoFSB1Iv6n44Jaul+ZDjmYUz2K0HbpUg0/oqm60O7wKz+X9FvyF rIXLvL3SOH7UrRMs7wFWCiTc15k+UX9GVmnR9RVTgnZkwCjslfvWlygZI/DHy5i1y17tsLMHp 0Z9FeRbPm8vqgtagKemN8m2HhnLBdVuNVHqZsA6aukeP8xBEBIDOm3GIxq3QIs45xP1iI2UuN W407cC1GejKLcVU5PPYT6CRpe590lrDh4lXep5Qt9FW9wpH5UBvdGWdRx9WATUFzrIf0jkmGS oc2kagHcDWcQdRZjQjatfSEKbzbORGhjWmx9D3urgdT0wnPtfA+QiINhBtQE5u+tNQwCidT/H SVDcpgz32R4oPRU3pUh+3CycZicnUwSIV2T0BnfkdcGb0tnzpF1OK4zya7y1Jnva4C85yaqNs YOFHNndaQrNUwyYR/uq8vsrNDQDRGYL+8gesSfiKQKdFrfm3TI28f4+wbaaWm109dqF046d0x 1EIidjyli3pbdHz6YojDiDKycVvwHO3RbvhuhgJKEbxR1LGufoh5MIbT9uQFVKHHF6bJ4s0mP UjhLElmm4rLxnOnMu84mwk3LLpxVai0mH80rXaInz9s+gVnQf2MBfOcgw4jmCfcmBPrk+JDpY pcntPTa3XfUI1JEaM6WuXZ9xFmXgT58aasfTR4lfts1rGCIB5te4Bs6hpZWC/b1HNnqUXheFj GR6dR8DKFmPBRDDB9gW7ChpLukQ5AoNf6QuRFcLHBnfEmM+rcDMyKhRp4USdDcT8XlH7hWuC1 uwS2vGs6Zy2Kn77/vs7SGd6LiGO7cpCF3xdGhB1PNrpJWYKf22bbNnxAtZdNKV/l2rich/fwh gGo49cxSrp2tom9EW/mOCEFyRYrLqjGNPGZSN5W7CCefs8xeezDJOWRvH6VT2PO8EjWPJYien T2mtY39MyghU8nlmeUPoK5XXxW6Ehj4EpFPKt71R1c05OpB8gEvrYNHoAouf6PCCEfHYtlTdY pMQVXp3UM+pRCJXekVzOepxNy0TQf32zHIPTKzaK/I4E9EPKQCirTPZCTC8vUFrARIgbCzLrY R3KCFIcmlCrmjRsoV Subject: Re: [Make-wifi-fast] Higher latency on upload under poor signal conditions 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: Tue, 16 Jun 2020 11:50:54 -0000 Hi Toke, > On Jun 16, 2020, at 13:35, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > Sebastian Moeller writes: >=20 >> Hi Michael, >>=20 >>=20 >>> On Jun 16, 2020, at 12:18, Michael Yartys via Make-wifi-fast = wrote: >>>=20 >>>=20 >>> From: Michael Yartys >>> Subject: Higher latency on upload under poor signal conditions >>> Date: June 16, 2020 at 12:18:38 GMT+2 >>> To: "make-wifi-fast@lists.bufferbloat.net" = >>> Reply-To: Michael Yartys >>>=20 >>>=20 >>> Hi >>>=20 >>> I decided to run some 8-stream TCP tests at the edge of the range of = my WiFi network, and I noticed that I get higher latency when I run an = upload compared to a download. The latency when downloading is pretty = steady at right above 30 ms, and when I run the upload it hovers around = 80-100 ms. I think I know why this happens, but I would like to read the = opinion of the mailing list. >>=20 >> My naive guess would be that air-time fairness by the AP only = directly affects the AP's own transmissions, the stations will in all = likelihood not have an fq_codel instance in its wifi-stack (I could be = wrong, but I do not believe that the 7260ac intel card actually uses = airtime fairness yet/at all). So the 80-100ms might just come from the = default wifi parameters which typically are adjusted for peak thoughput = instead of a balanced throughput latency under load set-point. Then = again that is my _guess_, so Kruger-Dunning might apply. >=20 > 'iw' will tell you: >=20 > $ iw phy | grep TXQ > * [ TXQS ]: FQ-CoDel-enabled intermediate TXQs Sweet! Thanks, as I hedged above, it seems like I am/was in = Kruger-Dunning territory ;) >=20 > $ lspci | grep Wireless > 02:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 = (rev 78) >=20 > Other than that, the 'lots of retries' theory does sound plausible. Or > it could be buffering in the firmware. Or a combination of all of that = :) Out of curiosity, how would one see the retries? Thanks Sebastian >=20 > -Toke