> On Mar 2, 2022, at 12:05 PM, Dave Täht wrote: > > > On Wed, Mar 02, 2022 at 02:55:26PM -0500, Michael Richardson wrote: >> >> > wrote: >>> need to prosper in the hybrid digital world. As all of you know, QoS is much >>> more than up and downlink speed and tough-to-quantify jitter is a huge part >>> of it. My measurement tool zoomready (at freecheckip.com >>> > and https://github.com/tevslin/zoomready ) makes >>> a more or less continuous measurement of jitter but is quite crude; so >> >> I think that Apple/Stuart did a good job inverting the jitter metric, and calling it >> Rounds/Revolutions per Minute. I suggest doing the same in your tool. > > Except it's NOT a jitter metric. It is a latency under load metric primarily aime > at testing in-band (http 2.0 or quic) AQM latency. Most of our other tests > to date have a tendency to favor FQ measurements. Thanks Dave, FWIW, the RPM metric is outlined in https://datatracker.ietf.org/doc/draft-ietf-ippm-responsiveness/ > > Certainly jitter can be pulled out of detailed measurements using some > of the proposed methodologies. See the rpm@lists.bufferbloat.net list > an archives for more details. > > We have a regular meeting on implementations and new data > at 10AM PDT tuesdays if anyone would like to join. > > > >> >> -- >> ] Never tell me the odds! | ipv6 mesh networks [ >> ] Michael Richardson, Sandelman Software Works | IoT architect [ >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ >> > > > >> _______________________________________________ >> Starlink mailing list >> Starlink@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/starlink > > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink