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 [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 71C103B29D for ; Fri, 15 May 2020 16:24:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1589574263; 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: in-reply-to:in-reply-to:references:references; bh=WwcuVdNjrq2mOvntVZ70nhfCrEaS5MDheww1qQ8x5uk=; b=KxmperhshmQ0i30ztvWZrqeeja7J3DgcejezSVHMWQoEKHxlVV1m22zi0gzDYJ+Bs+NUBL hIZaaBgydBwTKl1MT45MfyAVMsh4eDzAv9xKrq5n/GfZEICsFBRx91l1HN2ZCggjO2+iml V1NTN5XjVa+hBFtrmguscNOSRsNmnqc= Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-479-vqj3JQb8NQWSnphy_o1dww-1; Fri, 15 May 2020 16:24:20 -0400 X-MC-Unique: vqj3JQb8NQWSnphy_o1dww-1 Received: by mail-lf1-f72.google.com with SMTP id r143so1016717lff.13 for ; Fri, 15 May 2020 13:24:20 -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; bh=WwcuVdNjrq2mOvntVZ70nhfCrEaS5MDheww1qQ8x5uk=; b=I97nYcVdOgpOP9VbURTVanCu5k+7oZLSnNzrf0LNYZBVu+zceFr6DPvKHjh1haPyw0 WsyPzrz4D2tJFKggHnxO5SkvJ3Cr24laN702RDgvxnEOy93mz3qFZIltqBWbYDTijJoC tQ+evnk6y/z28qE4y4Stl7l+bFg3JAQA1jFANN68ivcnlng1nERSARZ2IKBke9WsPWgj pY27zpoi+GTbSBWpkahW1qEi77vZVdrTHg/X2KDoMJs34rSxeSmBQ2v1PZF2aE8BUlOf MuylQ7G5qEe/mEy4km5ydOmvtZ1FlB92t2JoGWwTBt9qB2xCwJRRqBPRqd+MQQ8WkKuY VKnA== X-Gm-Message-State: AOAM530FMnPpzySJ6NQphQoIkpA1ye3oX6Jr+JZ/Atcv3cuwJ4i+vhda amhfghKizLC6WP5TxXEt74hqgeSfoP+tOfk2FmE3kqgnBXwrBpnEITm64iJX2pOSRQq0JmQ1Jhy PsBHI2IxlvS4D6F6PcH9/PpJXBLTQrbwkcjQ= X-Received: by 2002:a2e:3209:: with SMTP id y9mr3141234ljy.154.1589574259008; Fri, 15 May 2020 13:24:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw+0z/zB/hThK4zlpL/gH3AmX/BCxvWwb6MJcsBQVkQOCj4BX9jUNiL1Ln4/GvswQVci8WZgg== X-Received: by 2002:a2e:3209:: with SMTP id y9mr3141220ljy.154.1589574258729; Fri, 15 May 2020 13:24:18 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk ([45.145.92.2]) by smtp.gmail.com with ESMTPSA id t15sm1847584lfg.57.2020.05.15.13.24.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 May 2020 13:24:18 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 276FA181510; Fri, 15 May 2020 22:24:17 +0200 (CEST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Tim Higgins , Bob McMahon Cc: Make-Wifi-fast In-Reply-To: References: <56a03e99-3337-bf4a-4743-deb93abb9592@smallnetbuilder.com> <6d8fc82a-cd32-31ba-023c-4dcd7822bb1d@smallnetbuilder.com> X-Clacks-Overhead: GNU Terry Pratchett Date: Fri, 15 May 2020 22:24:17 +0200 Message-ID: <87mu69q74e.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] SmallNetBuilder article: Does OFDMA Really Work? 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: Fri, 15 May 2020 20:24:23 -0000 Tim Higgins writes: > Thanks for the additional insights, Bob. How do you measure TCP connects? > > Does Dave or anyone else on the bufferbloat team want to comment on > Bob's comment that latency testing under "heavy traffic" isn't ideal? Well, it depends on what you want to measure. Loading the link with heavy traffic is a good way to show the worst-case behaviour of the system, as that will fill up the buffers and expose any latent bufferbloat. Which, as Bob points out, will tend to drown out any other source of latency, at least if all the queues are dumb FIFOs. However, if you want to specifically study, say, the media access latencies of the WiFi link, drowning it out with the order-of-magnitude higher latencies of bloat in the layers above is obviously going to obscure the signal somewhat. Which I think was basically Bob's point about "testing under heavy traffic"? > My impression is that the rtt_fair_var test I used in the article and > other RRUL-related Flent tests fully load the connection under test. > Am I incorrect? Yeah, the RRUL test (and friends) are specifically designed to load up the link to show the worst-case latency behaviour, including any bufferbloat. And, as per the above, as long as the system you're testing still has unresolved bloat issues, well, that is what you're going to be seeing most of... :) -Toke