From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 983B63B2A4 for ; Tue, 16 Jun 2020 09:06:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592312818; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pF1emh4iw7w6gXrxvWs9p2LpxqfOFv1ltDH0XdD7QRE=; b=hGia7ghMfNiorVZnp+H5qBitp1iAxHS1AQUS0plPPwOi2/iPxIZBPmsIqU+WfblnPPEn0N WpdCznvp3fcyHxhfXD6sXc67pKEHsi03EqVuApFPTqBAB9aYGjk1xrlkDZG9+T0GFTYrCu XFwaGpMT5nMs6s/kPOhFONt6oXwnsO8= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-255-IOf06qCQMmmbYxjaSuu5GA-1; Tue, 16 Jun 2020 09:06:56 -0400 X-MC-Unique: IOf06qCQMmmbYxjaSuu5GA-1 Received: by mail-wr1-f72.google.com with SMTP id e1so8287598wrm.3 for ; Tue, 16 Jun 2020 06:06:56 -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:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=A+GzOxhe7QIaBgcvGLJKAJAn8Eb6OahFvA5I2azohxE=; b=VtIYYi9Yvm4dEtprMlEWXb/asG+ho3Eos4s/Kswg9844QS9PG8lG/mZYcwDCQppchZ efPZyT3RPCAu9iSKt8c8ha8LXv0q1iWI+B8ydM1+H5f6MytR6m01BkZ0g1kYEKx4dc0U zi6/Xn3GaEGqlcYK9docyIaevdtNbg/BaJanGmePkmZ876ACYvpyrJVmnHw+nIRSYw4y 7cqtHe201+VH6iJmHwiUiJIkNV1h3AYlRcaycHyYJd/1X8b5RCyXqoXFBIJUhAzGoncF JvtpxMkJGZy49KoBhzgL1Ej/rx3prEKc7KJCcEDAJkehBuz16hed1h9kI/wQkdzwC3nU jFZA== X-Gm-Message-State: AOAM532WWpYtxh65C8qKNOf2cllPUEmmNmDYCgbadyarFCDvToD4PCEK pWCgKCCvholBhDMKZgc8snxYu3m4zhskQhOGIZYHqiWk8oIKBl3Xeno/+opZbm9feFfdRPsOz/P mjzX1h3VSQpv0uThTmTb/g7PcH3inL3JWsN0= X-Received: by 2002:a1c:408:: with SMTP id 8mr3121975wme.15.1592312815077; Tue, 16 Jun 2020 06:06:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyrHf2pBCOKkn1AhIVekPRl1a2jYZaqtlAaP0I3Qi52eUTGpCxRCQii05HV59g9Mizkase+FA== X-Received: by 2002:a1c:408:: with SMTP id 8mr3121920wme.15.1592312814401; Tue, 16 Jun 2020 06:06:54 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk ([2a0c:4d80:42:443::2]) by smtp.gmail.com with ESMTPSA id u13sm3915805wmm.6.2020.06.16.06.06.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jun 2020 06:06:53 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id F1D53181513; Tue, 16 Jun 2020 15:06:50 +0200 (CEST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Michael Yartys Cc: make-wifi-fast@lists.bufferbloat.net In-Reply-To: References: <87sgevz1iu.fsf@toke.dk> <709555FC-4203-486B-8B40-86FAD9F0294C@gmx.de> <87lfknz080.fsf@toke.dk> X-Clacks-Overhead: GNU Terry Pratchett Date: Tue, 16 Jun 2020 15:06:50 +0200 Message-ID: <87a713yxat.fsf@toke.dk> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 13:06:58 -0000 Michael Yartys writes: > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original = Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 > On Tuesday, 16 June 2020 14:03, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > >> Sebastian Moeller moeller0@gmx.de writes: >> >> > Hi Toke, >> > >> > > On Jun 16, 2020, at 13:35, Toke H=C3=B8iland-J=C3=B8rgensen toke@red= hat.com wrote: >> > > Sebastian Moeller moeller0@gmx.de writes: >> > > >> > > > Hi Michael, >> > > > >> > > > > On Jun 16, 2020, at 12:18, Michael Yartys via Make-wifi-fast mak= e-wifi-fast@lists.bufferbloat.net wrote: >> > > > > From: Michael Yartys michael.yartys@protonmail.com >> > > > > 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" make-wifi-fast@lists.= bufferbloat.net >> > > > > Reply-To: Michael Yartys michael.yartys@protonmail.com >> > > > > Hi >> > > > > I decided to run some 8-stream TCP tests at the edge of the rang= e 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 stea= dy 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 o= f the mailing list. >> > > > >> > > > My naive guess would be that air-time fairness by the AP only dire= ctly affects the AP's own transmissions, the stations will in all likelihoo= d 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 ye= t/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 thro= ughput 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 >> > >> > Sweet! Thanks, as I hedged above, it seems like I am/was in Kruger-Dun= ning territory ;) >> > >> > > $ 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 th= at :) >> > >> > Out of curiosity, how would one see the retries? >> >> Some hardware has counters, but not sure if the Intel devices expose >> anything. Otherwise, you'll need to sniff the air I'm afraid :/ > > Is this what I would be looking for (I only included the relevant part of= the output)? > > $ iw wlp18s0 station dump > tx packets:=09742091 > tx retries:=09417 > > This is the output after running an upload test and getting pretty > much the same results. I disabled and re-enabled the wireless NIC > before the test since that seems to reset the stats. It doesn't really > look like the retry rate is high, but I don't really know what's > considered high in the first place. That does not seem overly high, no. I guess 80ms could just be queueing delay, either in the firmware, or because your driver is not using TXQs... -Toke