<div dir="auto"><div>Adding in the author of irtt.<div dir="auto"><br></div><div dir="auto">You had a significant timer error rate in your 1ms testing. Modern hardware, particularly vms have great difficulty doing that below 3ms. </div><div dir="auto"><br></div><div dir="auto">Similarly the cloud can be highly noisy. I am presently testing a highly sdn - and virtualized networking fabric in a major DC... And the results are rather disturbing. I'd like to repeat your test suite inside that DC.</div><div dir="auto"><br></div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Dec 11, 2022, 11:21 AM MORTON JR., AL <<a href="mailto:acmorton@att.com">acmorton@att.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi IPPM,<br>
<br>
Prior to IETF-115, I shared a series of measurements with the IPPM list. We're looking at responsiveness and working latency with various metrics and multiple testing utilities. This message continues the discussion with new input.<br>
<br>
When I first published some measurements, Dave Taht added his assessment and included other relevant email lists in the discussion. I'm continuing to cross-post to all the lists in this thread.<br>
<br>
Dave originally suggested that I try a tool called irtt; I've done that now and these are the results.<br>
<br>
Bob McMahon: I queued your request to try your iperf2 tool behind the irtt measurements. I hope to make some more measurements this week... <br>
<br>
-=-=-=-=-=-=-=-=-=-=-=-=-=-<br>
<br>
We're testing a DOCIS 3.1 based service with 1Gbps down, nominally 22Mbps up. I used wired ETH connected to the DOCSIS modem's switch.<br>
<br>
Dave Taht made his server available for the irtt measurements. I installed irtt on a VM in my Macbook, the same VM that runs UDPST.  I ran quite a few tests to become familiar with irtt, so I'll just summarize the relevant ones here.<br>
<br>
I ran irtt with its traffic at the maximum allowed on Dave's server. The test duration was 10sec, with packets spaced at 1ms intervals from my VM client. This is the complete output:<br>
<br>
./irtt client -i 1ms -l 1250 -d 10s <a href="http://fremont.starlink.taht.net" rel="noreferrer noreferrer" target="_blank">fremont.starlink.taht.net</a><br>
<br>
                         Min     Mean   Median      Max  Stddev<br>
                         ---     ----   ------      ---  ------<br>
                RTT  46.63ms  51.58ms   51.4ms     58ms  1.55ms<br>
         send delay  20.74ms  25.57ms   25.4ms  32.04ms  1.54ms<br>
      receive delay   25.8ms  26.01ms  25.96ms  30.48ms   219µs<br>
<br>
      IPDV (jitter)   1.03µs   1.15ms   1.02ms   6.87ms   793µs<br>
          send IPDV    176ns   1.13ms    994µs   6.41ms   776µs<br>
       receive IPDV      7ns   79.8µs   41.7µs   4.54ms   140µs<br>
<br>
     send call time   10.1µs   55.8µs            1.34ms  30.3µs<br>
        timer error     68ns    431µs            6.49ms   490µs<br>
  server proc. time    680ns   2.43µs            47.7µs  1.73µs<br>
<br>
                duration: 10.2s (wait 174ms)<br>
   packets sent/received: 7137/7131 (0.08% loss)<br>
 server packets received: 7131/7137 (0.08%/0.00% loss up/down)<br>
     bytes sent/received: 8921250/8913750<br>
       send/receive rate: 7.14 Mbps / 7.13 Mbps<br>
           packet length: 1250 bytes<br>
             timer stats: 2863/10000 (28.63%) missed, 43.10% error<br>
acm@acm-ubuntu1804-1:~/goirtt/irtt$<br>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<br>
irtt supplies lots of info/stats about the RTT distribution. In the lightly loaded (7.1Mbps) scenario above, the RTT range is about 12 ms. The Mean and the Median are approximately the same.<br>
irtt also supplies Inter-Packet Delay Varition (IPDV), showing that the packets seem to be delayed more than the sending interval occasionally (Max of 6.8ms).<br>
irtt measurements indicate very low packet loss: no congestion at 7Mbps.<br>
<br>
For the opposite end of the congestion spectrum, I ran irtt with UDPST (RFC 9097) running in parallel (and using the Type C search algorithm). We pick-up a lot more RTT and wider RTT range in this scenario:<br>
<br>
irtt with udpst using Type C search = max load:<br>
<br>
                         Min     Mean   Median      Max   Stddev<br>
                         ---     ----   ------      ---   ------<br>
                RTT  47.58ms    118ms  56.53ms  301.6ms  90.28ms<br>
         send delay  24.05ms  94.85ms  33.38ms  278.5ms  90.26ms<br>
      receive delay  22.99ms  23.17ms  23.13ms  25.42ms    156µs<br>
<br>
      IPDV (jitter)    162ns   1.04ms    733µs   6.36ms   1.02ms<br>
          send IPDV   3.81µs   1.01ms    697µs   6.24ms   1.02ms<br>
       receive IPDV     88ns     93µs   49.8µs   1.48ms    145µs<br>
<br>
     send call time   4.28µs   39.3µs             903µs   32.4µs<br>
        timer error     86ns    287µs            6.13ms    214µs<br>
  server proc. time    670ns   3.59µs            19.3µs   2.26µs<br>
<br>
                duration: 10.9s (wait 904.8ms)<br>
   packets sent/received: 8305/2408 (71.01% loss)<br>
 server packets received: 2408/8305 (71.01%/0.00% loss up/down)<br>
     bytes sent/received: 10381250/3010000<br>
       send/receive rate: 8.31 Mbps / 2.47 Mbps<br>
           packet length: 1250 bytes<br>
             timer stats: 1695/10000 (16.95%) missed, 28.75% error<br>
acm@acm-ubuntu1804-1:~/goirtt/irtt$ <br>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-<br>
The irtt measurement of RTT range is now about 250ms in this maximally-loaded scenario.<br>
One key RTT difference is the Mean delay, which is now twice the Median with working load added by UDPST.<br>
Congestion is evident in the irtt loss measurements = 71%. However, the competing traffic did not break irtt's process or measurements.<br>
UDPST's measurements were ~22Mbps Capacity (steady-state), with high loss, and similar RTT range of 251 ms.<br>
<br>
<br>
Additional tests included load from UDPST at fixed rates: 14Mbps and 20Mbps. We compare the RTT range for all four conditions in the table below:<br>
<br>
Load with irtt   irtt RTT range    UDPST RTT range<br>
==================================================<br>
irtt alone            12ms               ---<br>
UDPST at 14Mbps       11ms               22ms <br>
UDPST at 20Mbps       14ms               46ms<br>
UDPST at MaxCap      250ms              251ms<br>
<br>
The unexpected result with irtt measurements is that the RTT range did not increase with load, where the UDPST RTT range increases with load. We're assuming that the majority of delay increases occur in the DOCSIS upstream queue and both test streams should see similar delay range as they do with maximum load. Perhaps there are some differences owing to the periodic irtt stream and the bursty UDPST stream (both are UDP), but this is speculation.<br>
<br>
To check that the test path was operating similarly with earlier tests, we ran a couple of NetworkQuality and UDPST tests as before:<br>
<br>
Comparison of NQ-vs, UDPST -A c, same columns as defined earlier.<br>
Working Latency & Capacity Summary (Upstream only)<br>
(capacity in Mbps, delays in ms, h and m are RPM categories, High and Medium)<br>
<br>
Net Qual                           UDPST (RFC 9097)                     <br>
UpCap     RPM    DelLD  DelMin     UpCap(stable)    RTTmin   RTTrange   <br>
22        276 m  217ms  11ms       23               28       0-252       <br>
22        291 m  206ms  11ms       ~22*             28*      0-251*  <br>
<br>
* UDPST test result with the ~7Mbps irtt stream present.     <br>
<br>
We found that uplink test results are similar to previous tests, and the new irtt results were collected under similar conditions.<br>
<br>
In conclusion, irtt provides a clear summary of the RTT distribution. Minimum, Mean, Median and Max RTT are useful individually and in combinations/comparisons. The irtt measurements compare favorably to those collected during IP-Layer Capacity tests with the UDPST utility.<br>
<br>
comments welcome, <br>
Al<br>
<br>
> -----Original Message-----<br>
> From: ippm <<a href="mailto:ippm-bounces@ietf.org" target="_blank" rel="noreferrer">ippm-bounces@ietf.org</a>> On Behalf Of MORTON JR., AL<br>
> Sent: Saturday, November 5, 2022 3:37 PM<br>
> To: Sebastian Moeller <<a href="mailto:moeller0@gmx.de" target="_blank" rel="noreferrer">moeller0@gmx.de</a>><br>
> Cc: Rpm <<a href="mailto:rpm@lists.bufferbloat.net" target="_blank" rel="noreferrer">rpm@lists.bufferbloat.net</a>>; Will Hawkins <<a href="mailto:hawkinsw@obs.cr" target="_blank" rel="noreferrer">hawkinsw@obs.cr</a>>;<br>
> <a href="mailto:ippm@ietf.org" target="_blank" rel="noreferrer">ippm@ietf.org</a><br>
> Subject: Re: [ippm] [Rpm] Preliminary measurement comparison of "Working<br>
> Latency" metrics<br>
> <br>
> *** Security Advisory: This Message Originated Outside of AT&T ***.<br>
> Reference <a href="http://cso.att.com/EmailSecurity/IDSP.html" rel="noreferrer noreferrer" target="_blank">http://cso.att.com/EmailSecurity/IDSP.html</a> for more information.<br>
> <br>
> Hi Sebastian, thanks for your comments and information.<br>
> I'll reply to a few key points in this top-post.<br>
> <br>
> Sebastian wrote:<br>
> >     [SM] DOCSIS ISPs traditionally provision higher peak rates than they<br>
> > advertise, with a DOCSIS modem/router with > 1 Gbps LAN capacity (even via<br>
> > bonded LAG) people in Germany routinely measure TCP/IPv4/HTTP goodput in the<br>
> > 1050 Mbps range. But typically gigabit ethernet limits the practically<br>
> > achievable throughput somewhat:<br>
> [acm]<br>
> Right, my ISP's CPE has Gig-E ports so I won't see any benefit from over-rate<br>
> provisioning.<br>
> <br>
> Sebastian wrote:<br>
> ...<br>
> > IPv4/TCP/RFC1323 timestamps payload:        1000 * ((1500 - 12 - 20 - 20)/(1500<br>
> + 38 + 4)) = 939.04 Mbps<br>
> ...<br>
> > Speedtests tend to report IPv4/TCP timestamps might be on depending on the<br>
> OS,<br>
> > but on-line speedtest almost never return the simple average rate over the<br>
> > measurement duration, but play "clever" tricks to exclude the start-up phase<br>
> > and to aggregate over multiple flows that invariably ending with results<br>
> that<br>
> > tend to exceed the hard limits shown above...<br>
> [acm]<br>
> My measurements with the Ookla desktop app on MacOS (shared earlier this week)<br>
> are very consistent at ~940Mbps Dn-stream, so timestamps calculation sounds<br>
> right.<br>
> My ISP specifies their service speed at 940Mbps, as though they assume<br>
> subscribers will measure using Ookla or other TCP tool. In fact, our team<br>
> hasn't seen such consistent results from Ookla or any TCP-based test in the<br>
> 1Gbps range, and this makes me wonder if there might be some test-recognition<br>
> here.<br>
> <br>
> FYI - UDPST uses a max packet size with is sub-MTU, to avoid fragmentation<br>
> when various encapsulations are encountered. Also, the definition of IP-Layer<br>
> Capacity in the various standards (e.g., RFC 9097) includes the bits in the IP<br>
> header in the total Capacity.<br>
> <br>
> So, instead of:<br>
> > Ethernet payload rate +VLAN:                1000 * ((1500)/(1500 + 38 + 4)) =<br>
> 972.76 Mbps<br>
> We have<br>
> Ethernet payload rate +VLAN:          1000 * ((1222)/(1222 + 38 + 4)) =  966.77<br>
> Mbps<br>
> and why our Maximum IP-Layer Capacity measurements are approx ~967 Mbps<br>
> <br>
> UDPST has an option to use datagrams for the traditional 1500 octet MTU (-T),<br>
> but a user could cause a lot of fragmentation on links with encapsulations wit<br>
> this option.<br>
> <br>
> acm wrote:<br>
> > > The comparison of networkQuality and goresponsiveness is somewhat<br>
> confounded<br>
> > > by the need to use the Apple server infrastructure for both these methods<br>
> ...<br>
> Sebastian wrote:<br>
> >     [SM] Puzzled, I thought when comparing the two networkQuality variants<br>
> > having the same back-end sort of helps be reducing the differences to the<br>
> > clients? But comparison to UDPST suffers somewhat.<br>
> [acm]<br>
> Yes, I was hoping to match-up the client and server implementations. Instead,<br>
> this might be more of a Client-X and Server-Y interoperability test (and could<br>
> explain some results?), but that was not to be.<br>
> <br>
> Thanks for your suggested command line for gores.<br>
> <br>
> IIRC one of your early messages, Sebastian, your MacOS indicates that 12.6 is<br>
> the latest. It's the same for me: my sufficiently powerful MacBook cannot<br>
> upgrade to Ventura for the latest in networkQuality versions. It would help us<br>
> who are doing some testing if the latest version of networkQuality could be<br>
> made installable for us, somehow...<br>
> <br>
> thanks again and regards,<br>
> Al<br>
> <br>
> <br>
> > -----Original Message-----<br>
> > From: Sebastian Moeller <<a href="mailto:moeller0@gmx.de" target="_blank" rel="noreferrer">moeller0@gmx.de</a>><br>
> > Sent: Friday, November 4, 2022 3:10 PM<br>
> > To: MORTON JR., AL <<a href="mailto:acmorton@att.com" target="_blank" rel="noreferrer">acmorton@att.com</a>><br>
> > Cc: Dave Täht <<a href="mailto:dave.taht@gmail.com" target="_blank" rel="noreferrer">dave.taht@gmail.com</a>>; rjmcmahon <<a href="mailto:rjmcmahon@rjmcmahon.com" target="_blank" rel="noreferrer">rjmcmahon@rjmcmahon.com</a>>;<br>
> Rpm<br>
> > <<a href="mailto:rpm@lists.bufferbloat.net" target="_blank" rel="noreferrer">rpm@lists.bufferbloat.net</a>>; <a href="mailto:ippm@ietf.org" target="_blank" rel="noreferrer">ippm@ietf.org</a>; Will Hawkins <<a href="mailto:hawkinsw@obs.cr" target="_blank" rel="noreferrer">hawkinsw@obs.cr</a>><br>
> > Subject: Re: [Rpm] [ippm] Preliminary measurement comparison of "Working<br>
> > Latency" metrics<br>
> ><br>
> > Hi Al,<br>
> ><br>
> ><br>
> > > On Nov 4, 2022, at 18:14, MORTON JR., AL via Rpm<br>
> <<a href="mailto:rpm@lists.bufferbloat.net" target="_blank" rel="noreferrer">rpm@lists.bufferbloat.net</a>><br>
> > wrote:<br>
> > ><br>
> > > Hi all,<br>
> > ><br>
> > > I have been working through the threads on misery metrics and lightweight<br>
> > sensing of bw and buffering, and with those insights and gold-nuggets in<br>
> mind,<br>
> > I'm iterating through testing the combinations of tools that Dave That and<br>
> Bob<br>
> > McMahon suggested.<br>
> > ><br>
> > > earlier this week, Dave wrote:<br>
> > >> How does networkQuality compare vs a vs your tool vs a vs<br>
> goresponsiveness?<br>
> > ><br>
> > > goresponsiveness installed flawlessly - very nice instructions and<br>
> getting-<br>
> > started info.<br>
> > ><br>
> > > Comparison of NetQual (networkQuality -vs), UDPST -A c,<br>
> > gores/goresponsiveness<br>
> > ><br>
> > > Working Latency & Capacity Summary on DOCSIS 3.1 access with 1 Gbps down-<br>
> > stream service<br>
> > > (capacity in Mbps, delays in ms, h and m are RPM categories, High and<br>
> > Medium)<br>
> > ><br>
> > > NetQual                            UDPST (RFC 9097)             gores<br>
> > > DnCap     RPM    DelLD  DelMin     DnCap    RTTmin   RTTrange   DnCap<br>
> RPM<br>
> > DelLD<br>
> > > 882       788 m  76ms   8ms        967      28       0-16       127<br>
> > (1382) 43ms<br>
> > > 892      1036 h  58ms   8          966      27       0-18       128<br>
> > (2124) 28ms<br>
> > > 887      1304 h  46ms   6          969      27       0-18       130<br>
> > (1478) 41ms<br>
> > > 885      1008 h  60ms   8          967      28       0-22       127<br>
> > (1490) 40ms<br>
> > > 894      1383 h  43ms   11         967      28       0-15       133<br>
> > (2731) 22ms<br>
> > ><br>
> > > NetQual                            UDPST (RFC 9097)             gores<br>
> > > UpCap     RPM    DelLD  DelMin     UpCap    RTTmin   RTTrange   UpCap<br>
> RPM<br>
> > DelLD<br>
> > > 21        327 m  183ms  8ms        22 (51)  28       0-253      12<br>
> > > 21        413 m  145ms  8          22 (43)  28       0-255      15<br>
> > > 22        273 m  220ms  6          23 (53)  28       0-259      10<br>
> > > 21        377 m  159ms  8          23 (51)  28       0-250      10<br>
> > > 22        281 m  214ms  11         23 (52)  28       0-250       6<br>
> > ><br>
> > > These tests were conducted in a round-robin fashion to minimize the<br>
> > possibility of network variations between measurements:<br>
> > > NetQual - rest - UDPST-Dn - rest- UDPST-Up - rest - gores - rest - repeat<br>
> > ><br>
> > > NetQual indicates the same reduced capacity in Downstream when compared to<br>
> > UDPST (940Mbps is the max for TCP payloads, while 967-970 is max for IP-<br>
> layer<br>
> > capacity, dep. on VLAN tag).<br>
> ><br>
> >     [SM] DOCSIS ISPs traditionally provision higher peak rates than they<br>
> > advertise, with a DOCSIS modem/router with > 1 Gbps LAN capacity (even via<br>
> > bonded LAG) people in Germany routinely measure TCP/IPv4/HTTP goodput in the<br>
> > 1050 Mbps range. But typically gigabit ethernet limits the practically<br>
> > achievable throughput somewhat:<br>
> ><br>
> > Ethernet payload rate:                      1000 * ((1500)/(1500 + 38)) =<br>
> >      975.29 Mbps<br>
> > Ethernet payload rate +VLAN:                1000 * ((1500)/(1500 + 38 + 4)) =<br>
> >      972.76 Mbps<br>
> > IPv4 payload (ethernet+VLAN):               1000 * ((1500 - 20)/(1500 + 38 + 4))<br>
> =<br>
> >              959.79 Mbps<br>
> > IPv6 payload (ethernet+VLAN):               1000 * ((1500 - 40)/(1500 + 38 + 4))<br>
> =<br>
> >              946.82 Mbps<br>
> > IPv4/TCP payload (ethernet+VLAN):   1000 * ((1500 - 20 - 20)/(1500 + 38<br>
> +<br>
> > 4)) =        946.82 Mbps<br>
> > IPv6/TCP payload (ethernet+VLAN):   1000 * ((1500 - 20 - 40)/(1500 + 38<br>
> +<br>
> > 4)) =        933.85 Mbps<br>
> > IPv4/TCP/RFC1323 timestamps payload:        1000 * ((1500 - 12 - 20 - 20)/(1500<br>
> +<br>
> > 38 + 4)) = 939.04 Mbps<br>
> > IPv6/TCP/RFC1323 timestamps payload:        1000 * ((1500 - 12 - 20 - 40)/(1500<br>
> +<br>
> > 38 + 4)) = 926.07 Mbps<br>
> ><br>
> ><br>
> > Speedtests tend to report IPv4/TCP timestamps might be on depending on the<br>
> OS,<br>
> > but on-line speedtest almost never return the simple average rate over the<br>
> > measurement duration, but play "clever" tricks to exclude the start-up phase<br>
> > and to aggregate over multiple flows that invariably ending with results<br>
> that<br>
> > tend to exceed the hard limits shown above...<br>
> ><br>
> ><br>
> > > Upstream capacities are not very different (a factor that made TCP methods<br>
> > more viable many years ago when most consumer access speeds were limited to<br>
> > 10's of Megabits).<br>
> ><br>
> >     [SM] My take on this is that this is partly due to the goal of ramping<br>
> > up very quickly and get away with a short measurement duration. That causes<br>
> > imprecision. As Dave said flent's RRUL test defaults to 60 seconds and I<br>
> often<br>
> > ran/run it for 5 to 10 minutes to get somewhat more reliable numbers (and<br>
> for<br>
> > timecourses to look at and reason about).<br>
> ><br>
> > > gores reports significantly lower capacity in both downstream and upstream<br>
> > measurements, a factor of 7 less than NetQual for downstream. Interestingly,<br>
> > the reduced capacity (taken as the working load) results in higher<br>
> > responsiveness: RPM meas are higher and loaded delays are lower for<br>
> > downstream.<br>
> ><br>
> >     [SM] Yepp, if you only fill-up the queue partially you will harvest less<br>
> > queueing delay and hence retain more responsiveness, albeit this really just<br>
> > seems to be better interpreted as go-responsiveness failing to achieve<br>
> > "working-conditions".<br>
> ><br>
> > I tend to run gores like this:<br>
> > time ./networkQuality --config <a href="http://mensura.cdn-apple.com" rel="noreferrer noreferrer" target="_blank">mensura.cdn-apple.com</a> --port 443 --path<br>
> > /api/v1/gm/config  --sattimeout 60 --extended-stats --logger-filename<br>
> > go_networkQuality_$(date +%Y%m%d_%H%M%S)<br>
> ><br>
> > --sattimeout 60 extends the time out for the saturation measurement somewhat<br>
> > (before I saw it simply failing on a 1 Gbps access link, it did give some<br>
> > diagnostic message though).<br>
> ><br>
> ><br>
> > ><br>
> > > The comparison of networkQuality and goresponsiveness is somewhat<br>
> confounded<br>
> > by the need to use the Apple server infrastructure for both these methods<br>
> (the<br>
> > documentation provides this option - thanks!). I don't have admin access to<br>
> > our server at the moment. But the measured differences are large despite the<br>
> > confounding factor.<br>
> ><br>
> >     [SM] Puzzled, I thought when comparing the two ntworkQuality variants<br>
> > having the same back-end sort of helps be reducing the differences to the<br>
> > clients? But comparison to UDPST suffers somewhat.<br>
> ><br>
> > ><br>
> > > goresponsiveness has its own, very different output format than<br>
> > networkQuality. There isn't a comparable "-v" option other than -debug<br>
> (which<br>
> > is extremely detailed). gores only reports RPM for the downstream.<br>
> ><br>
> >     [SM] I agree it would be nice if gores would grow a sequential mode as<br>
> > well.<br>
> ><br>
> ><br>
> > > I hope that these results will prompt more of the principle evangelists<br>
> and<br>
> > coders to weigh-in.<br>
> ><br>
> >     [SM] No luck ;) but at least "amateur hour" (aka me) is ready to<br>
> > discuss.<br>
> ><br>
> > ><br>
> > > It's also worth noting that the RTTrange reported by UDPST is the range<br>
> > above the minimum RTT, and represents the entire 10 second test. The<br>
> > consistency of the maximum of the range (~255ms) seems to indicate that<br>
> UDPST<br>
> > has characterized the length of the upstream buffer during measurements.<br>
> ><br>
> >     [SM] thanks for explaining that.<br>
> ><br>
> > Regards<br>
> >     Sebastian<br>
> ><br>
> > ><br>
> > > I'm sure there is more to observe that is prompted by these measurements;<br>
> > comments welcome!<br>
> > ><br>
> > > Al<br>
> > ><br>
> > ><br>
> > >> -----Original Message-----<br>
> > >> From: ippm <<a href="mailto:ippm-bounces@ietf.org" target="_blank" rel="noreferrer">ippm-bounces@ietf.org</a>> On Behalf Of MORTON JR., AL<br>
> > >> Sent: Tuesday, November 1, 2022 10:51 AM<br>
> > >> To: Dave Taht <<a href="mailto:dave.taht@gmail.com" target="_blank" rel="noreferrer">dave.taht@gmail.com</a>><br>
> > >> Cc: <a href="mailto:ippm@ietf.org" target="_blank" rel="noreferrer">ippm@ietf.org</a>; Rpm <<a href="mailto:rpm@lists.bufferbloat.net" target="_blank" rel="noreferrer">rpm@lists.bufferbloat.net</a>><br>
> > >> Subject: Re: [ippm] Preliminary measurement comparison of "Working<br>
> Latency"<br>
> > >> metrics<br>
> > >><br>
> > >> *** Security Advisory: This Message Originated Outside of AT&T ***.<br>
> > >> Reference <a href="http://cso.att.com/EmailSecurity/IDSP.html" rel="noreferrer noreferrer" target="_blank">http://cso.att.com/EmailSecurity/IDSP.html</a> for more<br>
> information.<br>
> > >><br>
> > >> Hi Dave,<br>
> > >> Thanks for trying UDPST (RFC 9097)!<br>
> > >><br>
> > >> Something you might try with starlink:<br>
> > >> use the -X option and UDPST will generate random payloads.<br>
> > >><br>
> > >> The measurements with -X will reflect the uncompressed that are possible.<br>
> > >> I tried this on a ship-board Internet access: uncompressed rate was<br>
> > 100kbps.<br>
> > >><br>
> > >> A few more quick replies below,<br>
> > >> Al<br>
> > >><br>
> > >>> -----Original Message-----<br>
> > >>> From: Dave Taht <<a href="mailto:dave.taht@gmail.com" target="_blank" rel="noreferrer">dave.taht@gmail.com</a>><br>
> > >>> Sent: Tuesday, November 1, 2022 12:22 AM<br>
> > >>> To: MORTON JR., AL <<a href="mailto:acmorton@att.com" target="_blank" rel="noreferrer">acmorton@att.com</a>><br>
> > >>> Cc: <a href="mailto:ippm@ietf.org" target="_blank" rel="noreferrer">ippm@ietf.org</a>; Rpm <<a href="mailto:rpm@lists.bufferbloat.net" target="_blank" rel="noreferrer">rpm@lists.bufferbloat.net</a>><br>
> > >>> Subject: Re: [ippm] Preliminary measurement comparison of "Working<br>
> > Latency"<br>
> > >>> metrics<br>
> > >>><br>
> > >>> Dear Al:<br>
> > >>><br>
> > >>> OK, I took your udpst tool for a spin.<br>
> > >>><br>
> > >>> NICE! 120k binary (I STILL work on machines with only 4MB of flash),<br>
> > >>> good feature set, VERY fast,<br>
> > >> [acm]<br>
> > >> Len Ciavattone (my partner in crime on several measurement projects) is<br>
> the<br>
> > >> lead coder: he has implemented many measurement tools extremely<br>
> > efficiently,<br>
> > >> this one in C-lang.<br>
> > >><br>
> > >>> and in very brief testing, seemed<br>
> > >>> to be accurate in the starlink case, though it's hard to tell with<br>
> > >>> them as the rate changes every 15s.<br>
> > >> [acm]<br>
> > >> Great! Our guiding principle developing UDPST has been to test the<br>
> accuracy<br>
> > of<br>
> > >> measurements against a ground-truth. It pays-off.<br>
> > >><br>
> > >>><br>
> > >>> I filed a couple bug reports on trivial stuff:<br>
> > >>><br>
> > >><br>
> ><br>
> <a href="https://urldefense.com/v3/__https://github.com/BroadbandForum/obudpst/issues/8" rel="noreferrer noreferrer" target="_blank">https://urldefense.com/v3/__https://github.com/BroadbandForum/obudpst/issues/8</a><br>
> > >>><br>
> > >><br>
> ><br>
> __;!!BhdT!iufMVqCyoH_CQ2AXdNJV1QSjl_7srzb_IznWE87U6E583vleKCIKpL3PBLwci5nOIEUc<br>
> > >>> SswH_opYmEw$<br>
> > >> [acm]<br>
> > >> much appreciated...  We have an OB-UDPST project meeting this Friday, can<br>
> > >> discuss then.<br>
> > >><br>
> > >>><br>
> > >>> (Adding diffserv and ecn washing or marking detection would be a nice<br>
> > >>> feature to have)<br>
> > >>><br>
> > >>> Aside from the sheer joy coming from the "it compiles! and runs!"<br>
> > >>> phase I haven't looked much further.<br>
> > >>><br>
> > >>> I left a copy running on one of my starlink testbeds -<br>
> > >>> <a href="http://fremont.starlink.taht.net" rel="noreferrer noreferrer" target="_blank">fremont.starlink.taht.net</a> - if anyone wants to try it. It's<br>
> > >>> instrumented with netperf, flent, irtt, iperf2 (not quite the latest<br>
> > >>> version from bob, but close), and now udpst, and good to about a gbit.<br>
> > >>><br>
> > >>> nice tool!<br>
> > >> [acm]<br>
> > >> Thanks again!<br>
> > >><br>
> > >>><br>
> > >>> Has anyone here played with crusader? (<br>
> > >>><br>
> > >><br>
> ><br>
> <a href="https://urldefense.com/v3/__https://github.com/Zoxc/crusader__;!!BhdT!iufMVqCy" rel="noreferrer noreferrer" target="_blank">https://urldefense.com/v3/__https://github.com/Zoxc/crusader__;!!BhdT!iufMVqCy</a><br>
> > >>> oH_CQ2AXdNJV1QSjl_7srzb_IznWE87U6E583vleKCIKpL3PBLwci5nOIEUcSswHm4Wtzjc$<br>
> > )<br>
> > >>><br>
> > >>> On Mon, Oct 31, 2022 at 4:30 PM Dave Taht <<a href="mailto:dave.taht@gmail.com" target="_blank" rel="noreferrer">dave.taht@gmail.com</a>> wrote:<br>
> > >>>><br>
> > >>>> On Mon, Oct 31, 2022 at 1:41 PM MORTON JR., AL <<a href="mailto:acmorton@att.com" target="_blank" rel="noreferrer">acmorton@att.com</a>><br>
> wrote:<br>
> > >>>><br>
> > >>>>>> have you tried irtt?<br>
> > >>><br>
> > >><br>
> ><br>
> (<a href="https://urldefense.com/v3/__https://github.com/heistp/irtt__;!!BhdT!iufMVqCyo" rel="noreferrer noreferrer" target="_blank">https://urldefense.com/v3/__https://github.com/heistp/irtt__;!!BhdT!iufMVqCyo</a><br>
> > >>> H_CQ2AXdNJV1QSjl_7srzb_IznWE87U6E583vleKCIKpL3PBLwci5nOIEUcSswHBSirIcE$<br>
> > )<br>
> > >>>>> I have not. Seems like a reasonable tool for UDP testing. The feature<br>
> I<br>
> > >>> didn't like in my scan of the documentation is the use of Inter-packet<br>
> > delay<br>
> > >>> variation (IPDV) instead of packet delay variation (PDV): variation from<br>
> > the<br>
> > >>> minimum (or reference) delay. The morbidly curious can find my analysis<br>
> in<br>
> > >> RFC<br>
> > >>> 5481:<br>
> > >>><br>
> > >><br>
> ><br>
> <a href="https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc5481__;" rel="noreferrer noreferrer" target="_blank">https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc5481__;</a>!!<br>
> > >>><br>
> > >><br>
> ><br>
> BhdT!iufMVqCyoH_CQ2AXdNJV1QSjl_7srzb_IznWE87U6E583vleKCIKpL3PBLwci5nOIEUcSswHt<br>
> > >>> T7QSlc$<br>
> > >>>><br>
> > >>>> irtt was meant to simulate high speed voip and one day<br>
> > >>>> videoconferencing. Please inspect the json output<br>
> > >>>> for other metrics. Due to OS limits it is typically only accurate to a<br>
> > >>>> 3ms interval. One thing it does admirably is begin to expose the<br>
> > >>>> sordid sump of L2 behaviors in 4g, 5g, wifi, and other wireless<br>
> > >>>> technologies, as well as request/grant systems like cable and gpon,<br>
> > >>>> especially when otherwise idle.<br>
> > >>>><br>
> > >>>> Here is a highres plot of starlink's behaviors from last year:<br>
> > >>>> <a href="https://urldefense.com/v3/__https://forum.openwrt.org/t/cake-w-" rel="noreferrer noreferrer" target="_blank">https://urldefense.com/v3/__https://forum.openwrt.org/t/cake-w-</a><br>
> adaptive-<br>
> > >>> bandwidth-<br>
> > >>><br>
> > >><br>
> ><br>
> historic/108848/3238__;!!BhdT!iufMVqCyoH_CQ2AXdNJV1QSjl_7srzb_IznWE87U6E583vle<br>
> > >>> KCIKpL3PBLwci5nOIEUcSswH_5Sms3w$<br>
> > >>>><br>
> > >>>> clearly showing them "optimizing for bandwidth" and changing next sat<br>
> > >>>> hop, and about a 40ms interval of buffering between these switches.<br>
> > >>>> I'd published elsewhere, if anyone cares, a preliminary study of what<br>
> > >>>> starlink's default behaviors did to cubic and BBR...<br>
> > >>>><br>
> > >>>>><br>
> > >>>>> irtt's use of IPDV means that the results won’t compare with UDPST,<br>
> and<br>
> > >>> possibly networkQuality. But I may give it a try anyway...<br>
> > >>>><br>
> > >>>> The more the merrier! Someday the "right" metrics will arrive.<br>
> > >>>><br>
> > >>>> As a side note, this paper focuses on RAN uplink latency<br>
> > >>>><br>
> > >>><br>
> > >><br>
> ><br>
> <a href="https://urldefense.com/v3/__https://dl.ifip.org/db/conf/itc/itc2021/1570740615" rel="noreferrer noreferrer" target="_blank">https://urldefense.com/v3/__https://dl.ifip.org/db/conf/itc/itc2021/1570740615</a><br>
> > >>><br>
> > >><br>
> ><br>
> .pdf__;!!BhdT!iufMVqCyoH_CQ2AXdNJV1QSjl_7srzb_IznWE87U6E583vleKCIKpL3PBLwci5nO<br>
> > >>> IEUcSswHgvqerjg$   which I think<br>
> > >>>> is a major barrier to most forms of 5G actually achieving good<br>
> > >>>> performance in a FPS game, if it is true for more RANs. I'd like more<br>
> > >>>> to be testing uplink latencies idle and with load, on all<br>
> > >>>> technologies.<br>
> > >>>><br>
> > >>>>><br>
> > >>>>> thanks again, Dave.<br>
> > >>>>> Al<br>
> > >>>>><br>
> > >>>>>> -----Original Message-----<br>
> > >>>>>> From: Dave Taht <<a href="mailto:dave.taht@gmail.com" target="_blank" rel="noreferrer">dave.taht@gmail.com</a>><br>
> > >>>>>> Sent: Monday, October 31, 2022 12:52 PM<br>
> > >>>>>> To: MORTON JR., AL <<a href="mailto:acmorton@att.com" target="_blank" rel="noreferrer">acmorton@att.com</a>><br>
> > >>>>>> Cc: <a href="mailto:ippm@ietf.org" target="_blank" rel="noreferrer">ippm@ietf.org</a>; Rpm <<a href="mailto:rpm@lists.bufferbloat.net" target="_blank" rel="noreferrer">rpm@lists.bufferbloat.net</a>><br>
> > >>>>>> Subject: Re: [ippm] Preliminary measurement comparison of "Working<br>
> > >>> Latency"<br>
> > >>>>>> metrics<br>
> > >>>>>><br>
> > >>>>>> Thank you very much for the steer to RFC9097. I'd completely missed<br>
> > >>> that.<br>
> > >>>>>><br>
> > >>>>>> On Mon, Oct 31, 2022 at 9:04 AM MORTON JR., AL <<a href="mailto:acmorton@att.com" target="_blank" rel="noreferrer">acmorton@att.com</a>><br>
> > >> wrote:<br>
> > >>>>>>><br>
> > >>>>>>> (astute readers may have guessed that I pressed "send" too soon on<br>
> > >>> previous<br>
> > >>>>>> message...)<br>
> > >>>>>>><br>
> > >>>>>>> I also conducted upstream tests this time, here are the results:<br>
> > >>>>>>> (capacity in Mbps, delays in ms, h and m are RPM categories, High<br>
> > >> and<br>
> > >>>>>> Medium)<br>
> > >>>>>>><br>
> > >>>>>>> Net Qual                           UDPST (RFC9097)<br>
> > >> Ookla<br>
> > >>>>>>> UpCap     RPM    DelLD  DelMin     UpCap    RTTmin   RTTrange<br>
> > >> UpCap<br>
> > >>>>>> Ping(no load)<br>
> > >>>>>>> 34        1821 h 33ms   11ms       23 (42)  28       0-252      22<br>
> > >>> 8<br>
> > >>>>>>> 22         281 m 214ms  8ms        27 (52)  25       5-248      22<br>
> > >>> 8<br>
> > >>>>>>> 22         290 m 207ms  8ms        27 (55)  28       0-253      22<br>
> > >>> 9<br>
> > >>>>>>> 21         330 m 182ms  11ms       23 (44)  28       0-255      22<br>
> > >>> 7<br>
> > >>>>>>> 22         334 m 180ms  9ms        33 (56)  25       0-255      22<br>
> > >>> 9<br>
> > >>>>>>><br>
> > >>>>>>> The Upstream capacity measurements reflect an interesting feature<br>
> > >> that<br>
> > >>> we<br>
> > >>>>>> can reliably and repeatably measure with UDPST. The first ~3 seconds<br>
> > >> of<br>
> > >>>>>> upstream data experience a "turbo mode" of ~50Mbps. UDPST displays<br>
> > >> this<br>
> > >>>>>> behavior in its 1 second sub-interval measurements and has a bimodal<br>
> > >>> reporting<br>
> > >>>>>> option that divides the complete measurement interval in two time<br>
> > >>> intervals to<br>
> > >>>>>> report an initial (turbo) max capacity and a steady-state max<br>
> capacity<br>
> > >>> for the<br>
> > >>>>>> later intervals. The UDPST capacity results present both<br>
> measurements:<br>
> > >>> steady-<br>
> > >>>>>> state first.<br>
> > >>>>>><br>
> > >>>>>> Certainly we can expect bi-model distributions from many ISPs, as,<br>
> for<br>
> > >>>>>> one thing, the "speedboost" concept remains popular, except that it's<br>
> > >>>>>> misnamed, as it should be called speed-subtract or speed-lose. Worse,<br>
> > >>>>>> it is often configured "sneakily", in that it doesn't kick in for the<br>
> > >>>>>> typical observed duration of the test, for some, they cut the<br>
> > >>>>>> available bandwidth about 20s in, others, 1 or 5 minutes.<br>
> > >>>>>><br>
> > >>>>>> One of my biggest issues with the rpm spec so far is that it should,<br>
> > >>>>>> at least, sometimes, run randomly longer than the overly short<br>
> > >>>>>> interval it runs for and the tools also allow for manual override of<br>
> > >>> length.<br>
> > >>>>>><br>
> > >>>>>> we caught a lot of tomfoolery with flent's rrul test running by<br>
> > >> default<br>
> > >>> for<br>
> > >>>>>> 1m.<br>
> > >>>>>><br>
> > >>>>>> Also, AQMs on the path can take a while to find the optimal drop or<br>
> > >> mark<br>
> > >>> rate.<br>
> > >>>>>><br>
> > >>>>>>><br>
> > >>>>>>> The capacity processing in networkQuality and Ookla appear to report<br>
> > >>> the<br>
> > >>>>>> steady-state result.<br>
> > >>>>>><br>
> > >>>>>> Ookla used to basically report the last result. Also it's not a good<br>
> > >>>>>> indicator of web traffic behavior at all, watching the curve<br>
> > >>>>>> go up much more slowly in their test on say, fiber 2ms, vs starlink,<br>
> > >>>>>> (40ms)....<br>
> > >>>>>><br>
> > >>>>>> So adding another mode - how quickly is peak bandwidth actually<br>
> > >>>>>> reached, would be nice.<br>
> > >>>>>><br>
> > >>>>>> I haven't poked into the current iteration of the goresponsiveness<br>
> > >>>>>> test at all: <a href="https://urldefense.com/v3/__https://github.com/network-" rel="noreferrer noreferrer" target="_blank">https://urldefense.com/v3/__https://github.com/network-</a><br>
> > >>>>>><br>
> > >>><br>
> > >><br>
> ><br>
> quality/goresponsiveness__;!!BhdT!giGhURYxqguQCyB3NT8rE0vADdzxcQ2eCzfS4NRMsdvb<br>
> > >>>>>> K2bOqw0uMPbFeJ7PxzxTc48iQFubYTxxmyA$   it<br>
> > >>>>>> would be good to try collecting more statistics and histograms and<br>
> > >>>>>> methods of analyzing the data in that libre-source version.<br>
> > >>>>>><br>
> > >>>>>> How does networkQuality compare vs a vs your tool vs a vs<br>
> > >>> goresponsiveness?<br>
> > >>>>>><br>
> > >>>>>>> I watched the upstream capacity measurements on the Ookla app, and<br>
> > >>> could<br>
> > >>>>>> easily see the initial rise to 40-50Mbps, then the drop to ~22Mbps<br>
> for<br>
> > >>> most of<br>
> > >>>>>> the test which determined the final result.<br>
> > >>>>>><br>
> > >>>>>> I tend to get upset when I see ookla's new test flash a peak result<br>
> in<br>
> > >>>>>> the seconds and then settle on some lower number somehow.<br>
> > >>>>>> So far as I know they are only sampling the latency every 250ms.<br>
> > >>>>>><br>
> > >>>>>>><br>
> > >>>>>>> The working latency is about 200ms in networkQuality and about 280ms<br>
> > >>> as<br>
> > >>>>>> measured by UDPST (RFC9097). Note that the networkQuality minimum<br>
> > >> delay<br>
> > >>> is<br>
> > >>>>>> ~20ms lower than the UDPST RTTmin, so this accounts for some of the<br>
> > >>> difference<br>
> > >>>>>> in working latency.  Also, we used the very dynamic Type C load<br>
> > >>>>>> adjustment/search algorithm in UDPST during all of this testing,<br>
> which<br>
> > >>> could<br>
> > >>>>>> explain the higher working latency to some degree.<br>
> > >>>>>>><br>
> > >>>>>>> So, it's worth noting that the measurements needed for assessing<br>
> > >>> working<br>
> > >>>>>> latency/responsiveness are available in the UDPST utility, and that<br>
> > >> the<br>
> > >>> UDPST<br>
> > >>>>>> measurements are conducted on UDP transport (used by a growing<br>
> > >> fraction<br>
> > >>> of<br>
> > >>>>>> Internet traffic).<br>
> > >>>>>><br>
> > >>>>>> Thx, didn't know of this work til now!<br>
> > >>>>>><br>
> > >>>>>> have you tried irtt?<br>
> > >>>>>><br>
> > >>>>>>><br>
> > >>>>>>> comments welcome of course,<br>
> > >>>>>>> Al<br>
> > >>>>>>><br>
> > >>>>>>>> -----Original Message-----<br>
> > >>>>>>>> From: ippm <<a href="mailto:ippm-bounces@ietf.org" target="_blank" rel="noreferrer">ippm-bounces@ietf.org</a>> On Behalf Of MORTON JR., AL<br>
> > >>>>>>>> Sent: Sunday, October 30, 2022 8:09 PM<br>
> > >>>>>>>> To: <a href="mailto:ippm@ietf.org" target="_blank" rel="noreferrer">ippm@ietf.org</a><br>
> > >>>>>>>> Subject: Re: [ippm] Preliminary measurement comparison of "Working<br>
> > >>>>>> Latency"<br>
> > >>>>>>>> metrics<br>
> > >>>>>>>><br>
> > >>>>>>>><br>
> > >>>>>>>> Hi again RPM friends and IPPM'ers,<br>
> > >>>>>>>><br>
> > >>>>>>>> As promised, I repeated the tests shared last week, this time<br>
> > >> using<br>
> > >>> both<br>
> > >>>>>> the<br>
> > >>>>>>>> verbose (-v) and sequential (-s) dwn/up test options of<br>
> > >>> networkQuality. I<br>
> > >>>>>>>> followed Sebastian's calculations as well.<br>
> > >>>>>>>><br>
> > >>>>>>>> Working Latency & Capacity Summary<br>
> > >>>>>>>><br>
> > >>>>>>>> Net Qual                           UDPST<br>
> > >>> Ookla<br>
> > >>>>>>>> DnCap     RPM    DelLD  DelMin     DnCap    RTTmin   RTTrange<br>
> > >>> DnCap<br>
> > >>>>>>>> Ping(no load)<br>
> > >>>>>>>> 885       916 m  66ms   8ms        970      28       0-20<br>
> > >> 940<br>
> > >>> 8<br>
> > >>>>>>>> 888      1355 h  44ms   8ms        966      28       0-23<br>
> > >> 940<br>
> > >>> 8<br>
> > >>>>>>>> 891      1109 h  54ms   8ms        968      27       0-19<br>
> > >> 940<br>
> > >>> 9<br>
> > >>>>>>>> 887      1141 h  53ms   11ms       966      27       0-18<br>
> > >> 937<br>
> > >>> 7<br>
> > >>>>>>>> 884      1151 h  52ms   9ms        968      28       0-20<br>
> > >> 937<br>
> > >>> 9<br>
> > >>>>>>>><br>
> > >>>>>>>> With the sequential test option, I noticed that networkQuality<br>
> > >>> achieved<br>
> > >>>>>> nearly<br>
> > >>>>>>>> the maximum capacity reported almost immediately at the start of a<br>
> > >>> test.<br>
> > >>>>>>>> However, the reported capacities are low by about 60Mbps,<br>
> > >> especially<br>
> > >>> when<br>
> > >>>>>>>> compared to the Ookla TCP measurements.<br>
> > >>>>>>>><br>
> > >>>>>>>> The loaded delay (DelLD) is similar to the UDPST RTTmin + (the<br>
> > >> high<br>
> > >>> end of<br>
> > >>>>>> the<br>
> > >>>>>>>> RTTrange), for example 54ms compared to (27+19=46). Most of the<br>
> > >>>>>> networkQuality<br>
> > >>>>>>>> RPM measurements were categorized as "High". There doesn't seem to<br>
> > >>> be much<br>
> > >>>>>>>> buffering in the downstream direction.<br>
> > >>>>>>>><br>
> > >>>>>>>><br>
> > >>>>>>>><br>
> > >>>>>>>>> -----Original Message-----<br>
> > >>>>>>>>> From: ippm <<a href="mailto:ippm-bounces@ietf.org" target="_blank" rel="noreferrer">ippm-bounces@ietf.org</a>> On Behalf Of MORTON JR., AL<br>
> > >>>>>>>>> Sent: Monday, October 24, 2022 6:36 PM<br>
> > >>>>>>>>> To: <a href="mailto:ippm@ietf.org" target="_blank" rel="noreferrer">ippm@ietf.org</a><br>
> > >>>>>>>>> Subject: [ippm] Preliminary measurement comparison of "Working<br>
> > >>> Latency"<br>
> > >>>>>>>>> metrics<br>
> > >>>>>>>>><br>
> > >>>>>>>>><br>
> > >>>>>>>>> Hi RPM friends and IPPM'ers,<br>
> > >>>>>>>>><br>
> > >>>>>>>>> I was wondering what a comparison of some of the "working<br>
> > >> latency"<br>
> > >>>>>> metrics<br>
> > >>>>>>>>> would look like, so I ran some tests using a service on DOCSIS<br>
> > >>> 3.1, with<br>
> > >>>>>> the<br>
> > >>>>>>>>> downlink provisioned for 1Gbps.<br>
> > >>>>>>>>><br>
> > >>>>>>>>> I intended to run apple's networkQuality, UDPST (RFC9097), and<br>
> > >>> Ookla<br>
> > >>>>>>>> Speedtest<br>
> > >>>>>>>>> with as similar connectivity as possible (but we know that the<br>
> > >>> traffic<br>
> > >>>>>> will<br>
> > >>>>>>>>> diverge to different servers and we can't change that aspect).<br>
> > >>>>>>>>><br>
> > >>>>>>>>> Here's a quick summary of yesterday's results:<br>
> > >>>>>>>>><br>
> > >>>>>>>>> Working Latency & Capacity Summary<br>
> > >>>>>>>>><br>
> > >>>>>>>>> Net Qual                UDPST                        Ookla<br>
> > >>>>>>>>> DnCap     RPM           DnCap    RTTmin   RTTVarRnge DnCap<br>
> > >>> Ping(no<br>
> > >>>>>> load)<br>
> > >>>>>>>>> 878       62            970      28       0-19       941      6<br>
> > >>>>>>>>> 891       92            970      27       0-20       940      7<br>
> > >>>>>>>>> 891       120           966      28       0-22       937      9<br>
> > >>>>>>>>> 890       112           970      28       0-21       940      8<br>
> > >>>>>>>>> 903       70            970      28       0-16       935      9<br>
> > >>>>>>>>><br>
> > >>>>>>>>> Note: all RPM values were categorized as Low.<br>
> > >>>>>>>>><br>
> > >>>>>>>>> networkQuality downstream capacities are always on the low side<br>
> > >>> compared<br>
> > >>>>>> to<br>
> > >>>>>>>>> others. We would expect about 940Mbps for TCP, and that's mostly<br>
> > >>> what<br>
> > >>>>>> Ookla<br>
> > >>>>>>>>> achieved. I think that a longer test duration might be needed to<br>
> > >>> achieve<br>
> > >>>>>> the<br>
> > >>>>>>>>> actual 1Gbps capacity with networkQuality; intermediate values<br>
> > >>> observed<br>
> > >>>>>> were<br>
> > >>>>>>>>> certainly headed in the right direction. (I recently upgraded to<br>
> > >>>>>> Monterey<br>
> > >>>>>>>> 12.6<br>
> > >>>>>>>>> on my MacBook, so should have the latest version.)<br>
> > >>>>>>>>><br>
> > >>>>>>>>> Also, as Sebastian Moeller's message to the list reminded me, I<br>
> > >>> should<br>
> > >>>>>> have<br>
> > >>>>>>>>> run the tests with the -v option to help with comparisons. I'll<br>
> > >>> repeat<br>
> > >>>>>> this<br>
> > >>>>>>>>> test when I can make time.<br>
> > >>>>>>>>><br>
> > >>>>>>>>> The UDPST measurements of RTTmin (minimum RTT observed during<br>
> > >> the<br>
> > >>> test)<br>
> > >>>>>> and<br>
> > >>>>>>>>> the range of variation above the minimum (RTTVarRnge) add-up to<br>
> > >>> very<br>
> > >>>>>>>>> reasonable responsiveness IMO, so I'm not clear why RPM graded<br>
> > >>> this<br>
> > >>>>>> access<br>
> > >>>>>>>> and<br>
> > >>>>>>>>> path as "Low". The UDPST server I'm using is in NJ, and I'm in<br>
> > >>> Chicago<br>
> > >>>>>>>>> conducting tests, so the minimum 28ms is typical. UDPST<br>
> > >>> measurements<br>
> > >>>>>> were<br>
> > >>>>>>>> run<br>
> > >>>>>>>>> on an Ubuntu VM in my MacBook.<br>
> > >>>>>>>>><br>
> > >>>>>>>>> The big disappointment was that the Ookla desktop app I updated<br>
> > >>> over the<br>
> > >>>>>>>>> weekend did not include the new responsiveness metric! I<br>
> > >> included<br>
> > >>> the<br>
> > >>>>>> ping<br>
> > >>>>>>>>> results anyway, and it was clearly using a server in the nearby<br>
> > >>> area.<br>
> > >>>>>>>>><br>
> > >>>>>>>>> So, I have some more work to do, but I hope this is interesting-<br>
> > >>> enough<br>
> > >>>>>> to<br>
> > >>>>>>>>> start some comparison discussions, and bring-out some<br>
> > >> suggestions.<br>
> > >>>>>>>>><br>
> > >>>>>>>>> happy testing all,<br>
> > >>>>>>>>> Al<br>
> > >>>>>>>>><br>
> > >>>>>>>>><br>
> > >>>>>>>>><br>
> > >>>>>>>>><br>
> > >>>>>>>>> _______________________________________________<br>
> > >>>>>>>>> ippm mailing list<br>
> > >>>>>>>>> <a href="mailto:ippm@ietf.org" target="_blank" rel="noreferrer">ippm@ietf.org</a><br>
> > >>>>>>>>><br>
> > >>>>>>>><br>
> > >>>>>><br>
> > >>><br>
> > >><br>
> ><br>
> <a href="https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm__;!!Bhd" rel="noreferrer noreferrer" target="_blank">https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm__;!!Bhd</a><br>
> > >>>>>>>>><br>
> > >>>>>>>><br>
> > >>>>>><br>
> > >>><br>
> > >><br>
> ><br>
> T!hd5MvMQw5eiICQbsfoNaZBUS38yP4YIodBvz1kV5VsX_cGIugVnz5iIkNqi6fRfIQzWef_xKqg4$<br>
> > >>>>>>>><br>
> > >>>>>>>> _______________________________________________<br>
> > >>>>>>>> ippm mailing list<br>
> > >>>>>>>> <a href="mailto:ippm@ietf.org" target="_blank" rel="noreferrer">ippm@ietf.org</a><br>
> > >>>>>>>><br>
> > >>>>>><br>
> > >>><br>
> > >><br>
> ><br>
> <a href="https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm__;!!Bhd" rel="noreferrer noreferrer" target="_blank">https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm__;!!Bhd</a><br>
> > >>>>>>>> T!g-<br>
> > >>>>>><br>
> > >>><br>
> FsktB_l9MMSGNUge6FXDkL1npaKtKcyDtWLcTZGpCunxNNCcTImH8YjC9eUT262Wd8q1EBpiw$<br>
> > >>>>>>><br>
> > >>>>>>> _______________________________________________<br>
> > >>>>>>> ippm mailing list<br>
> > >>>>>>> <a href="mailto:ippm@ietf.org" target="_blank" rel="noreferrer">ippm@ietf.org</a><br>
> > >>>>>>><br>
> > >>>>>><br>
> > >>><br>
> > >><br>
> ><br>
> <a href="https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm__;!!Bhd" rel="noreferrer noreferrer" target="_blank">https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm__;!!Bhd</a><br>
> > >>>>>><br>
> > >>><br>
> > >><br>
> ><br>
> T!giGhURYxqguQCyB3NT8rE0vADdzxcQ2eCzfS4NRMsdvbK2bOqw0uMPbFeJ7PxzxTc48iQFub_gMs<br>
> > >>>>>> KXU$<br>
> > >>>>>><br>
> > >>>>>><br>
> > >>>>>><br>
> > >>>>>> --<br>
> > >>>>>> This song goes out to all the folk that thought Stadia would work:<br>
> > >>>>>> <a href="https://urldefense.com/v3/__https://www.linkedin.com/posts/dtaht_the-" rel="noreferrer noreferrer" target="_blank">https://urldefense.com/v3/__https://www.linkedin.com/posts/dtaht_the-</a><br>
> > >>> mushroom-<br>
> > >>>>>> song-activity-6981366665607352320-<br>
> > >>>>>><br>
> > >>><br>
> > >><br>
> ><br>
> FXtz__;!!BhdT!giGhURYxqguQCyB3NT8rE0vADdzxcQ2eCzfS4NRMsdvbK2bOqw0uMPbFeJ7PxzxT<br>
> > >>>>>> c48iQFub34zz4iE$<br>
> > >>>>>> Dave Täht CEO, TekLibre, LLC<br>
> > >>>><br>
> > >>>><br>
> > >>>><br>
> > >>>> --<br>
> > >>>> This song goes out to all the folk that thought Stadia would work:<br>
> > >>>> <a href="https://urldefense.com/v3/__https://www.linkedin.com/posts/dtaht_the-" rel="noreferrer noreferrer" target="_blank">https://urldefense.com/v3/__https://www.linkedin.com/posts/dtaht_the-</a><br>
> > >>> mushroom-song-activity-6981366665607352320-<br>
> > >>><br>
> > >><br>
> ><br>
> FXtz__;!!BhdT!iufMVqCyoH_CQ2AXdNJV1QSjl_7srzb_IznWE87U6E583vleKCIKpL3PBLwci5nO<br>
> > >>> IEUcSswHLHDpSWs$<br>
> > >>>> Dave Täht CEO, TekLibre, LLC<br>
> > >>><br>
> > >>><br>
> > >>><br>
> > >>> --<br>
> > >>> This song goes out to all the folk that thought Stadia would work:<br>
> > >>> <a href="https://urldefense.com/v3/__https://www.linkedin.com/posts/dtaht_the-" rel="noreferrer noreferrer" target="_blank">https://urldefense.com/v3/__https://www.linkedin.com/posts/dtaht_the-</a><br>
> > >> mushroom-<br>
> > >>> song-activity-6981366665607352320-<br>
> > >>><br>
> > >><br>
> ><br>
> FXtz__;!!BhdT!iufMVqCyoH_CQ2AXdNJV1QSjl_7srzb_IznWE87U6E583vleKCIKpL3PBLwci5nO<br>
> > >>> IEUcSswHLHDpSWs$<br>
> > >>> Dave Täht CEO, TekLibre, LLC<br>
> > >> _______________________________________________<br>
> > >> ippm mailing list<br>
> > >> <a href="mailto:ippm@ietf.org" target="_blank" rel="noreferrer">ippm@ietf.org</a><br>
> > >><br>
> ><br>
> <a href="https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm__;!!Bhd" rel="noreferrer noreferrer" target="_blank">https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm__;!!Bhd</a><br>
> > >> T!jOVBx7DlKXbDMiZqaYSUhBtkSdUvfGpYUyGvLerdLsLBJZPMzEGcbhC9ZSzsZOd1dYC-<br>
> > rDt9HLI$<br>
> > > _______________________________________________<br>
> > > Rpm mailing list<br>
> > > <a href="mailto:Rpm@lists.bufferbloat.net" target="_blank" rel="noreferrer">Rpm@lists.bufferbloat.net</a><br>
> > ><br>
> ><br>
> <a href="https://urldefense.com/v3/__https://lists.bufferbloat.net/listinfo/rpm__;!!Bhd" rel="noreferrer noreferrer" target="_blank">https://urldefense.com/v3/__https://lists.bufferbloat.net/listinfo/rpm__;!!Bhd</a><br>
> > T!h8K1vAtpaGSUHpuVMl5sZgi7k-f64BEaV91ypoUokPjn57v_79iCnp7W-<br>
> > mERYCyuCd9e9PY3aNLkSw$<br>
> <br>
> _______________________________________________<br>
> ippm mailing list<br>
> <a href="mailto:ippm@ietf.org" target="_blank" rel="noreferrer">ippm@ietf.org</a><br>
> <a href="https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm__;!!Bhd" rel="noreferrer noreferrer" target="_blank">https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ippm__;!!Bhd</a><br>
> T!h-glaezufaCxidYk1xzTF48dbEz67JPIJjPA_nweL8YvDu6Z3TmG0A37k_DQ15FIzzwoeCLOEaw$<br>
</blockquote></div></div></div>