David Schinazi via Bloat 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
Yes. Stuart was pretty clear about this being the reason for the decision.
It seemed sound then
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
>
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
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
> (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.
--
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