From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 7FFA73CB35 for ; Thu, 2 Apr 2020 06:20:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1585822838; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wa/7e/rnBgtYxWQ4hSvsumKBNmXb5O7djFQSuHq3XPk=; b=P0OAbAxwcKQMWhsIN7lFqz7wah4MC8aFHM6YIRT3Sb/BrmyKw1W2HHZg1zCdwYhUPdySW8 IgwkD1dgwKBY1DEYxBimLT8oKgJhT8IIuKrWjQ6ommEI8Xrf25wqnHJZmQiSuvapOOTTVl 6mofBrch/eeOvwHs3dSkycueKAq4Jac= Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com [209.85.208.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-489-QCqYcVxPMG6ALkFOTMl8Qg-1; Thu, 02 Apr 2020 06:20:35 -0400 X-MC-Unique: QCqYcVxPMG6ALkFOTMl8Qg-1 Received: by mail-lj1-f199.google.com with SMTP id i19so430623ljn.17 for ; Thu, 02 Apr 2020 03:20:35 -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=fkjdb+z2yoawAiLcPDdyB2cdL+4inHhM5ms8qk8SbZM=; b=p5wBpPCvawO/V0iClH8eaA8vPswWY65BNErSKw/2G+SaVp3bPBazUeOlQKCHpqJbOR Qr6MrtdIIiU6LfVclhTjoIplcRNdFg5tIzrJqpaxVm4kXt+XgwjF1SXeG548/lqWqWf4 cCV5HWXWknP9oJNIjg7eTfB+nT8Rlhqxhbmwkxq3Xe4grdTQh2NnmtXl7XnL6zQA7tN+ cBA5DSs8oUN+hiNqBUCXRnhI8E2otKSRTxqHiYxIBdfKlfAelh5zVOPYU8+6YrcnGdw/ YSycXtYnSxx5rdcMtrEDVFrqoYupY7l+42klBb5q02YxOGUBOq57v4676dkHzcK4617h g9yA== X-Gm-Message-State: AGi0PuaI8UEVwqdEM2jaGgoX29fZTKtAg8GBhB1KmMFM7J1IMizPdMgK 9ixKWkQNE3l3hxB3AKOhALVSTYIxPpItoBBiHxQZLs3jAHvx+Ulcx4rWnn9tfPaOgxN698/rLMf ZUddU1gkj4TUCiTVCLVbNIx4sTXaVvbQP92k= X-Received: by 2002:a19:cb41:: with SMTP id b62mr1706044lfg.21.1585822833801; Thu, 02 Apr 2020 03:20:33 -0700 (PDT) X-Google-Smtp-Source: APiQypJRgzUKMd0CiIqn2WGCanr33BgJrA5/BWZQUfHSpDahWp94+gebHbXBNp78e/Oe0R6Mtr6H4Q== X-Received: by 2002:a19:cb41:: with SMTP id b62mr1706034lfg.21.1585822833514; Thu, 02 Apr 2020 03:20:33 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk ([45.145.92.2]) by smtp.gmail.com with ESMTPSA id i2sm3215438ljj.72.2020.04.02.03.20.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Apr 2020 03:20:32 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 387DA18158D; Thu, 2 Apr 2020 12:20:32 +0200 (CEST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Tim Higgins , Make-Wifi-fast In-Reply-To: References: X-Clacks-Overhead: GNU Terry Pratchett Date: Thu, 02 Apr 2020 12:20:32 +0200 Message-ID: <87mu7ufatr.fsf@toke.dk> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] Must a WiFi link be fully loaded to get an accurate latency measurement? 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: Thu, 02 Apr 2020 10:20:38 -0000 Tim Higgins writes: > One of the things I've been wondering about as I work on OFDMA testing is= how > heavily a WiFi link needs to be loaded. > As far as I can tell, all (most/many) of the flent scripts basically have > netperf TCP/IP streams running full tilt. > > I guess put another way, how effective are the anti-bufferbloat methods a= t > reducing latency on a moderately loaded link? Well, the anti-bufferbloat mitigations aim at managing packet queues. But if the link is not loaded to capacity, packets will generally be sent out as soon as they arrive, so there won't *be* any queue to manage. Which means that as far as queueing is concerned, it doesn't really matter what you do. There are other factors that can impact the latency of an idle link, of course, but we haven't really touched those much when working on the bloat stuff.. > In terms of WiFi, do I need to run a link at 90+ airtime congestion to > see OFDMA work it's magic? Or would the lack of available airtime > hinder it working? Now this is a good question. I would expect that OFDMA to only kick in if there is actually data queued for multiple stations. I mean, otherwise it doesn't really gain you much? There is probably also a tradeoff in how long you hold back packets while waiting for more data to show up; wait too long and you're just wasting airtime, but if you don't wait long enough you get no benefit. How the firmware scheduler manages that is of course vital; but I guess that's what you're trying to find out? :) -Toke