Re: [Bloat] goresponsiveness learned a few tricks...

2024-01-08 Thread Sebastian Moeller via Bloat
Hi David, > On Jan 9, 2024, at 00:15, David Schinazi wrote: > > My understanding is that Apple chose to report RTT as an inverse because > people are used to "higher number means better". The target audience for > network speed tests is the average slightly-tech-savvy consumer, and those >

Re: [Bloat] goresponsiveness learned a few tricks...

2024-01-08 Thread David Schinazi via Bloat
My understanding is that Apple chose to report RTT as an inverse because people are used to "higher number means better". The target audience for network speed tests is the average slightly-tech-savvy consumer, and those aren't all familiar with what latency means. Also, car enthusiasts like RPMs

Re: [Bloat] goresponsiveness learned a few tricks...

2024-01-08 Thread Sebastian Moeller via Bloat
Hi Julien, On 8 January 2024 22:04:23 CET, Juliusz Chroboczek wrote: >> (h++ps://github.com/network-quality/draft-ietf-ippm-responsiveness). > >There's quite a few good ideas in this draft, but the one that I find >intriguing is reporting RTT values in RPM (units of 1/60 Hz) rather than

Re: [Bloat] goresponsiveness learned a few tricks...

2024-01-08 Thread Juliusz Chroboczek via Bloat
> (h++ps://github.com/network-quality/draft-ietf-ippm-responsiveness). There's quite a few good ideas in this draft, but the one that I find intriguing is reporting RTT values in RPM (units of 1/60 Hz) rather than milliseconds. I wonder how well this works. I'll experiment with undergrads. --

[Bloat] goresponsiveness learned a few tricks...

2024-01-08 Thread Sebastian Moeller via Bloat
Just a quick shoutout to Will Hawkins goresponsiveness effort (h++ps://github.com/network-quality/goresponsiveness: open source go implementation along the lines of the RPM IETF responsiveness draft (h++ps://github.com/network-quality/draft-ietf-ippm-responsiveness). The goal I think is a