From: Sebastian Moeller <moeller0@gmx.de>
To: Rpm <rpm@lists.bufferbloat.net>, "Dave Täht" <dave.taht@gmail.com>
Cc: Brennen Smith <brennen@ookla.com>
Subject: [Rpm] Latency tests in comparison, Ookla, dslreports, flent
Date: Sat, 18 Jun 2022 16:13:44 +0200 [thread overview]
Message-ID: <F085AACA-5728-48A2-ACC9-22F8130C5F5E@gmx.de> (raw)
[-- Attachment #1: Type: text/plain, Size: 8896 bytes --]
So here are results from the same Nokia 6.2 Android11 device, once over LTE (with the ISP's shaper set to apparently 25/10) and once over WiFI (5GHz) where the actual limit comes from SQM set to 105/36 (on a VDSL2-link with 116/37 sync). Both results are less than perfect, but over LTE the bloat is quite painful (due to the lack of a time resolved display it is hard to estimate how much of the High result is just happening during the initial peak of the transfer, where it seems that the shaper kicks in with a delay, or potentially it might just allow bursts).
Looking at the time resolved results for LTE on DSL reports (http://www.dslreports.com/speedtest/71047363) seems to indicate that it is not only the initial peak:
Download (LTE):
Download (WiFi):
Upload (LTE):
Upload (WiFi):
(I clearly have some issues with repeated upload delay up to 600-800ms in this test). A flent test over ethernet however shows RTT maxima (of seprate RTT measurement flows so not intra-dataflow RTTs, max tcp_rtt stays below 50ms for all data flows, but that is already smoothed data IIRC):
Ping (ms)::ICMP : 28.54 28.40 36.00 ms 1397
Ping (ms)::UDP 0 (CS0) : 28.50 28.33 35.21 ms 1628
Ping (ms)::UDP 1 (CS1) : 28.11 28.22 34.73 ms 1628
Ping (ms)::UDP 2 (CS2) : 26.49 26.26 34.93 ms 1628
Ping (ms)::UDP 3 (CS3) : 26.46 26.32 34.05 ms 1628
Ping (ms)::UDP 4 (CS4) : 26.40 26.21 34.65 ms 1628
Ping (ms)::UDP 5 (CS5) : 26.47 26.28 35.08 ms 1628
Ping (ms)::UDP 6 (CS6) : 29.32 29.26 37.26 ms 1628
Ping (ms)::UDP 7 (CS7) : 28.90 28.81 35.97 ms 1628
TCP download avg : 11.90 N/A N/A Mbits/s 1628
TCP download sum : 95.22 N/A N/A Mbits/s 1628
TCP download::0 (CS0) : 11.95 12.30 15.07 Mbits/s 1628
TCP download::1 (CS1) : 11.72 12.23 13.94 Mbits/s 1628
TCP download::2 (CS2) : 11.92 12.31 14.31 Mbits/s 1628
TCP download::3 (CS3) : 11.84 12.29 14.00 Mbits/s 1628
TCP download::4 (CS4) : 11.83 12.30 14.12 Mbits/s 1628
TCP download::5 (CS5) : 12.05 12.31 15.01 Mbits/s 1628
TCP download::6 (CS6) : 11.93 12.30 14.96 Mbits/s 1628
TCP download::7 (CS7) : 11.98 12.32 14.47 Mbits/s 1628
TCP totals : 125.83 N/A N/A Mbits/s 1628
TCP upload avg : 3.83 N/A N/A Mbits/s 1628
TCP upload sum : 30.61 N/A N/A Mbits/s 1628
TCP upload::0 (CS0) : 4.27 4.31 7.17 Mbits/s 1628
TCP upload::0 (CS0)::tcp_cwnd : 13.37 13.00 20.00 955
TCP upload::0 (CS0)::tcp_delivery_rate : 4.12 4.23 5.57 955
TCP upload::0 (CS0)::tcp_pacing_rate : 5.31 5.45 7.65 955
TCP upload::0 (CS0)::tcp_rtt : 35.24 34.45 48.87 955
TCP upload::0 (CS0)::tcp_rtt_var : 2.36 1.98 11.09 955
TCP upload::1 (CS1) : 1.74 1.76 2.70 Mbits/s 1628
TCP upload::1 (CS1)::tcp_cwnd : 8.18 8.00 13.00 951
TCP upload::1 (CS1)::tcp_delivery_rate : 1.65 1.72 2.95 951
TCP upload::1 (CS1)::tcp_pacing_rate : 2.21 2.29 4.39 951
TCP upload::1 (CS1)::tcp_rtt : 52.63 51.92 73.08 949
TCP upload::1 (CS1)::tcp_rtt_var : 6.30 6.00 16.16 949
TCP upload::2 (CS2) : 4.24 4.31 5.30 Mbits/s 1628
TCP upload::2 (CS2)::tcp_cwnd : 13.10 13.00 18.00 948
TCP upload::2 (CS2)::tcp_delivery_rate : 4.11 4.22 5.19 947
TCP upload::2 (CS2)::tcp_pacing_rate : 5.25 5.42 7.13 948
TCP upload::2 (CS2)::tcp_rtt : 34.81 34.56 46.65 946
TCP upload::2 (CS2)::tcp_rtt_var : 2.43 2.11 10.81 946
TCP upload::3 (CS3) : 4.27 4.38 5.19 Mbits/s 1628
TCP upload::3 (CS3)::tcp_cwnd : 13.29 13.00 18.00 949
TCP upload::3 (CS3)::tcp_delivery_rate : 4.13 4.25 5.08 948
TCP upload::3 (CS3)::tcp_pacing_rate : 5.30 5.52 6.82 949
TCP upload::3 (CS3)::tcp_rtt : 34.99 34.73 45.70 947
TCP upload::3 (CS3)::tcp_rtt_var : 2.39 2.03 11.09 947
TCP upload::4 (CS4) : 4.26 4.37 5.23 Mbits/s 1628
TCP upload::4 (CS4)::tcp_cwnd : 13.33 13.00 18.00 950
TCP upload::4 (CS4)::tcp_delivery_rate : 4.10 4.23 5.05 949
TCP upload::4 (CS4)::tcp_pacing_rate : 5.27 5.47 6.79 950
TCP upload::4 (CS4)::tcp_rtt : 35.29 34.94 46.76 947
TCP upload::4 (CS4)::tcp_rtt_var : 2.43 2.11 11.32 947
TCP upload::5 (CS5) : 4.25 4.32 5.51 Mbits/s 1628
TCP upload::5 (CS5)::tcp_cwnd : 14.06 14.00 19.00 948
TCP upload::5 (CS5)::tcp_delivery_rate : 4.10 4.24 5.24 947
TCP upload::5 (CS5)::tcp_pacing_rate : 5.23 5.42 6.94 948
TCP upload::5 (CS5)::tcp_rtt : 37.51 36.82 47.57 943
TCP upload::5 (CS5)::tcp_rtt_var : 2.27 1.96 9.95 943
TCP upload::6 (CS6) : 3.81 3.87 5.01 Mbits/s 1628
TCP upload::6 (CS6)::tcp_cwnd : 12.08 12.00 17.52 949
TCP upload::6 (CS6)::tcp_delivery_rate : 3.68 3.80 4.96 948
TCP upload::6 (CS6)::tcp_pacing_rate : 4.70 4.88 6.50 949
TCP upload::6 (CS6)::tcp_rtt : 35.90 35.32 48.65 946
TCP upload::6 (CS6)::tcp_rtt_var : 2.67 2.33 9.81 946
TCP upload::7 (CS7) : 3.77 3.85 4.85 Mbits/s 1628
TCP upload::7 (CS7)::tcp_cwnd : 11.91 12.00 17.00 950
TCP upload::7 (CS7)::tcp_delivery_rate : 3.62 3.77 4.83 949
TCP upload::7 (CS7)::tcp_pacing_rate : 4.63 4.83 6.34 949
TCP upload::7 (CS7)::tcp_rtt : 35.91 35.15 47.73 947
TCP upload::7 (CS7)::tcp_rtt_var : 2.56 2.31 9.04 947
cpu_stats_root@192.168.42.1::load : 0.37 0.35 0.83 1214
Now, this clearly is not apples to apples, since flent does not run on my phone and this test was over ethernet, but I think it demonstrates that the upload latency spikes over WiFi are not my ISP's responsibility, but something in my WiFi set-up that needs fixing.
I am living next door to a CO and "my" LTE antenna is around 20-30m away (distance phone to antenna element).
Might I propose to add time resolved latency plots to the two time resolved speed lines in the detailed results view, please?
Regards
Sebastian
[-- Attachment #2.1: Type: text/html, Size: 20935 bytes --]
[-- Attachment #2.2: 5CE82154-D304-48C4-80B3-9A14BA7B198D.png --]
[-- Type: image/png, Size: 134353 bytes --]
[-- Attachment #2.3: F9B1C8D6-DE9E-4D72-A41E-CE514AE85F40.png --]
[-- Type: image/png, Size: 129801 bytes --]
[-- Attachment #2.4: Screen Shot 2022-06-18 at 15.38.48.png --]
[-- Type: image/png, Size: 194365 bytes --]
[-- Attachment #2.5: Screen Shot 2022-06-18 at 15.46.56.png --]
[-- Type: image/png, Size: 192191 bytes --]
[-- Attachment #2.6: Screen Shot 2022-06-18 at 15.39.32.png --]
[-- Type: image/png, Size: 190132 bytes --]
[-- Attachment #2.7: Screen Shot 2022-06-18 at 15.47.11.png --]
[-- Type: image/png, Size: 187906 bytes --]
[-- Attachment #2.8: rrul_var_-_IPv4_SQM_cake_layer-cake_LLA-ETH_OH34_U097pct36000of36998K-D090pct105000of116797K_work-horse-eth0_2_TurrisOmnia-TurrisOS.5.3.6-pppoe-wan-eth2.7_2_bridged-BTHH5A-OpenWrt-r18441-ba7cee05ed-Hvt-VDSL100_2_netperf-eu.bufferbloat.net.png --]
[-- Type: image/png, Size: 340567 bytes --]
reply other threads:[~2022-06-18 14:13 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/rpm.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F085AACA-5728-48A2-ACC9-22F8130C5F5E@gmx.de \
--to=moeller0@gmx.de \
--cc=brennen@ookla.com \
--cc=dave.taht@gmail.com \
--cc=rpm@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox