From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8ACB33B2A4 for ; Tue, 16 Jun 2020 07:35:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592307341; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GWMKIWDiIoFtXzvyLl3kLbybkbSF34V26tEOLfWSQLE=; b=AqY4Z9eErw7bK5Dh1Bnzwu3ENINneGRd8F0TzUYlFrU0or1KIRLugFpCMCU6a0Byj4/oyo qiec4BRO6iENOeGcrSctWbEEVO9qJG3R7+jSzFJVXd00FRcySB2YxY0XQUbhz/XBj4LVsy /V1kKn1Zi1i0ybAuRRZtpzNFiakU8f4= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-100-075xe1kGPdy1JfdGZp6vsg-1; Tue, 16 Jun 2020 07:35:40 -0400 X-MC-Unique: 075xe1kGPdy1JfdGZp6vsg-1 Received: by mail-wm1-f72.google.com with SMTP id p24so1134890wmc.1 for ; Tue, 16 Jun 2020 04:35:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=GWMKIWDiIoFtXzvyLl3kLbybkbSF34V26tEOLfWSQLE=; b=cllrBeHuGyubhGRosKWuhG/fpzCyYDsLNRVXuGKJxiblfzLPvqSUEBXl5G/ZGQJcA6 Njc4ELIPnrw4ptyixtK7JqjuJb6GlcuQN26ew/IfRyujPe2aK+ZRhAO0SLBU9ZnDpXiz palEgl+H/Qfh9g+8aQC9hmHnQ7QKozHT/DbZ4raUf4obDqzMDg8Nd7gI428mLgmdwP9L XIECzNFIR9+Japh6od1/LaJ2GCPAFwj4cRch7Zs90iauSWvc4bRgDbbKy3nsMwrZnF1d 8bezaFIcqZdit5os6uyrKqMobqkfwJRB/fmGJRnp+2tscG0oEXxpsRhwjB75II+Fjqc6 zOYw== X-Gm-Message-State: AOAM532JdtPno1rbrSxwwlZajX0wjkfuijxE4CD09xjKvC+AFWcsfiRE /ZfzZ/PVys1G0syqvOGV62EtHWOVAv7dxPtKvvXCrLitGpQkruWO2oXBcPJGrM4T5iwAE9wiunS dB6Rhe9XEPVd2YRJ4zZ7wJTjO5ap+t0cqOYM= X-Received: by 2002:adf:f245:: with SMTP id b5mr2547640wrp.303.1592307338671; Tue, 16 Jun 2020 04:35:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyCnfIgDojJrSbhwn/npqaS0i6SbrEVEdQAUZubsNBVu0GQZRa9IvdxIUyfFXeyfMwXlZz+PQ== X-Received: by 2002:adf:f245:: with SMTP id b5mr2547627wrp.303.1592307338469; Tue, 16 Jun 2020 04:35:38 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk ([45.145.92.2]) by smtp.gmail.com with ESMTPSA id c66sm3820230wma.20.2020.06.16.04.35.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jun 2020 04:35:37 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 420901814F7; Tue, 16 Jun 2020 13:35:37 +0200 (CEST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Sebastian Moeller , Michael Yartys , Michael Yartys via Make-wifi-fast In-Reply-To: References: X-Clacks-Overhead: GNU Terry Pratchett Date: Tue, 16 Jun 2020 13:35:37 +0200 Message-ID: <87sgevz1iu.fsf@toke.dk> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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:35:42 -0000 Sebastian Moeller writes: > Hi Michael, > > >> On Jun 16, 2020, at 12:18, Michael Yartys via Make-wifi-fast wrote: >> >> >> 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 >> >> >> Hi >> >> 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. > > 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. 'iw' will tell you: $ iw phy | grep TXQ * [ TXQS ]: FQ-CoDel-enabled intermediate TXQs $ lspci | grep Wireless 02:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78) 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 :) -Toke