From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5FFF13B2A4; Sun, 26 Sep 2021 18:24:00 -0400 (EDT) Received: by mail-io1-xd29.google.com with SMTP id e82so20196651iof.5; Sun, 26 Sep 2021 15:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=fVbdweE2sq2/Z3qWNxCn7WEnr3EDiCNObVOGiiCQ1pM=; b=Gbr7VjNK6Rzqqc7Tzd8xgzFdAMzuOsx4u4WAJBrYtDUWFK0FS5TlK7Z8z7Kvd7UAvs PXnbt/qMUUmeT4nLFSXLXD5TXNGvvE6c6Lxz7IrRApQaJJx/V1ptKbcWCdEmFZ9vpNMO VVAv3stRH5gY8j2aSPdc5cVZMXAehzz3vvRbN/nP22dpkqCLYq+IXtdSmSoDvXXV25Mo z2tQQKke3UlMnqPWsKvsGK6GXv7tvPzzz1BMcpKamKL47sKUKV7CKRFbaFnfotr9spUB +jUtI7HT/d8r0hl6cZAvJsfZ7GgTvkOwXc3Zv8/B2MzwFSDTmueHW+Zi/i4ZRzAdm+gU xwMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=fVbdweE2sq2/Z3qWNxCn7WEnr3EDiCNObVOGiiCQ1pM=; b=XN0MqbZKFe3sbyRRfNGWYFDqt4mda2M2A7ycKY/50b1rPCFTdhxYMdcBqIJCWXYys5 PBOyZRts4buXvmIBw5G9oZYSCve+AMHU4znh7ZEmALAbAmhfPr96sjQ3heaH2dO/4XWv Qz1cHhL4bM+yaeEAVQY/SgdZzkID0s3rALqcObxFzc4yPEY3/68Cl4Jl64R4c2NcwAT4 wSsZMDGyJIahYri0sGUa4J/YF4J24QwzI0lRl4JEFf44OzPkc1g00BkkBTtFlHQID+9h 3xs6CGFdfr+YEchhNi049cOPVrZEiWyWMMHU6y/9homlggbc2xu7x+UOxyI4uQ29E57b YhsQ== X-Gm-Message-State: AOAM5330iHWPttpkZtfIbgxGj1Y+t+g7s2CiAOAcVLCSeDnRs/IvoC1y 6sZ2LK7p+KLzyjIeEjgiwSftQtq8kOYxy68oUjNqb4VXeDLFgw== X-Google-Smtp-Source: ABdhPJyyZ0pwIDX86f6gHiRFGbODWZRFJ8lEcEUmsnrH5YaOCC5fUdlqkQIS/hJL7zn/RQpr42JHgoI/YDzC+NgB3DI= X-Received: by 2002:a02:6d10:: with SMTP id m16mr19214871jac.60.1632695039595; Sun, 26 Sep 2021 15:23:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Sun, 26 Sep 2021 15:23:46 -0700 Message-ID: To: Ben Greear , rpm@lists.bufferbloat.net Cc: starlink@lists.bufferbloat.net, Make-Wifi-fast Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Rpm] [Starlink] RFC: Latency test case text and example report. X-BeenThere: rpm@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: revolutions per minute - a new metric for measuring responsiveness List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2021 22:24:00 -0000 Thx ben. Why is it we get the most work done on bloat on the weekends? Adding in the rpm (mostly apple at this point), folk. Their test shipped last week as part of ios15 and related and is documented here: https://support.apple.com/en-us/HT212313 I am glad to hear more folk are working on extending tr398. The numbers you are reporting are at least, better, than with what we were getting from the ath10k 5+ years ago, before we reworked the stack. See the 100 station test here: https://blog.linuxplumbersconf.org/2016/ocw/system/presentations/3963/origi= nal/linuxplumbers_wifi_latency-3Nov.pdf And I'd hoped that a gang scheduler could be applied on top of that work to take advantage of the new features in wifi 6. That said, I don't have any reports of ofdma or du working at all, from anyone, at this point. On Sun, Sep 26, 2021 at 2:59 PM Ben Greear wrote: > > I have been working on a latency test that I hope can be included in the = TR398 issue 3 > document. It is based somewhat on Toke's paper on buffer bloat and laten= cy testing, > with a notable change that I'm doing this on 32 stations in part of the t= est. > > I implemented this test case, and an example run against an enterprise gr= ade AX AP > is here. There could still be bugs in my implementation, but I think it = is at least > close to correct: > > http://www.candelatech.com/examples/tr398v3-latency-report.pdf > > TLDR: Runs OK with single station, but sees 1+second one-way latency wit= h 32 stations and high load, and UDP often > is not able to see any throughput at all, I guess due to too many pack= ets being lost > or something. I hope to run against some cutting-edge OpenWRT APs soo= n. packet caps are helpful. > > One note on TCP Latency: This is time to transmit a 64k chunk of data ov= er TCP, not a single > frame. This number is dependent on the size of the IW as for the minimum number of round trips required. It's 10 packets in linux, and recently osx moved from 4 to 10. After that the actual completion time is governed by loss or marking - and in the case of truly excessively latencies as you are experiencing tcp tends to send more packets after a timeout. (packet caps are helpful) > My testbed used 32 Intel ax210 radios as stations in this test. > > I am interested in feedback from this list if anyone has opinions. So far as I knew the wifi stack rework and api was now supported by most of the intel chipsets. AQL was also needed. please see if you have any "aqm" files: cat /sys/debug/kernel/ieee*/phy*/aq= m > > Here is text of the test case: > > The Latency test intends to verify latency under low, high, and maximum A= P traffic load, with > 1 and 32 stations. Traffic load is 4 bi-directional TCP streams for each = station, plus a > low speed UDP connection to probe latency. > > Test Procedure > > DUT should be configured for 20Mhz on 2.4Ghz and 80Mhz on 5Ghz and statio= ns should use > two spatial streams. > > 1: For each combination of: 2.4Ghz N, 5Ghz AC, 2.4Ghz AX, 5Ghz AX: > > 2: Configure attenuators to emulate 2-meter distance between stations and= AP. > > 3: Create 32 stations and allow one to associate with the DUT. The other= 31 are admin-down. > > 4: Create AP to Station (download) TCP stream, and run for 120 seconds, r= ecoard > throughput as 'maximum_load'. Stop this connection. > > 5: Calculate offered_load as 1% of maximum_load. > > 6: Create 4 TCP streams on each active station, each configured for Uploa= d and Download rate of > offered_load / (4 * active_station_count * 2). > > 6: Create 1 UDP stream on each active station, configured for 56kbps traf= fic Upload and 56kbps traffic Download. > > 7: Start all TCP and UDP connections. Wait 30 seconds to let traffic set= tle. > > 8: Every 10 seconds for 120 seconds, record one-way download latency over= the last 10 seconds for each UDP connection. Depending on test > equipment features, this may mean you need to start/stop the UDP ever= y 10 seconds or clear the UDP connection > counters. > > 9: Calculate offered_load as 70% of maximum_load, and repeat steps 6 - 9 = inclusive. > > 10: Calculate offered_load as 125% of maximum_load, and repeat steps 6 - = 9 inclusive. > > 11: Allow the other 31 stations to associate, and repeat steps 5 - 11 inc= lusive with all 32 stations active. > > > Pass/Fail Criteria > > 1: For each test configuration running at 1% of maximum load: Average of= all UDP latency samples must be less than 10ms. > 2: For each test configuration running at 1% of maximum load: Maximum of= all UDP latency samples must be less than 20ms. > 3: For each test configuration running at 70% of maximum load: Average o= f all UDP latency samples must be less than 20ms. > 4: For each test configuration running at 70% of maximum load: Maximum o= f all UDP latency samples must be less than 40ms. > 5: For each test configuration running at 125% of maximum load: Average = of all UDP latency samples must be less than 50ms. > 6: For each test configuration running at 125% of maximum load: Maximum = of all UDP latency samples must be less than 100ms. > 7: For each test configuration: Each UDP connection upload throughput mus= t be at least 1/2 of requested UDP speed for final 10-second test interval. > 8: For each test configuration: Each UDP connection download throughput m= ust be at least 1/2 of requested UDP speed for final 10-second test interva= l. > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink --=20 Fixing Starlink's Latencies: https://www.youtube.com/watch?v=3Dc9gLo6Xrwgw Dave T=C3=A4ht CEO, TekLibre, LLC