[Bloat] Ookla - Introducing a Better Measure of Latency

[Bloat] Ookla - Introducing a Better Measure of Latency

[Christoph Paasch]

[-- Attachment #1: Type: text/plain, Size: 257 bytes --]

Ookla's measure of "loaded latency":

https://www.ookla.com/articles/introducing-loaded-latency <https://www.ookla.com/articles/introducing-loaded-latency>

This will hopefully be a shift in how operators approach the bufferbloat problem.


Christoph

[-- Attachment #2: Type: text/html, Size: 587 bytes --]

Re: [Bloat] Ookla - Introducing a Better Measure of Latency

[Kathleen Nichols]

a ping by any other name...

Has anyone ever done a rigorous study to see how well ping delays 
correspond to the delay that information-carrying packets experience?

On 5/12/22 10:15 AM, Christoph Paasch via Bloat wrote:
> Ookla's measure of "loaded latency":
> 
> https://www.ookla.com/articles/introducing-loaded-latency 
> <https://www.ookla.com/articles/introducing-loaded-latency>
> 
> This will hopefully be a shift in how operators approach the bufferbloat 
> problem.
> 
> 
> Christoph
> 
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Ookla - Introducing a Better Measure of Latency

[Christoph Paasch]

I'm not aware of any rigorous study. But, just from the code, I know ICMP ping in many cases has a different traffic-class and thus implicitly gets quite a different treatment than real traffic.

However, Ookla uses TCP (port 8080) to probe the latency in their app.


Christoph

> On May 12, 2022, at 12:44 PM, Kathleen Nichols <nichols@pollere.net> wrote:
> 
> a ping by any other name...
> 
> Has anyone ever done a rigorous study to see how well ping delays correspond to the delay that information-carrying packets experience?
> 
> On 5/12/22 10:15 AM, Christoph Paasch via Bloat wrote:
>> Ookla's measure of "loaded latency":
>> https://www.ookla.com/articles/introducing-loaded-latency <https://www.ookla.com/articles/introducing-loaded-latency>
>> This will hopefully be a shift in how operators approach the bufferbloat problem.
>> Christoph
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
> 
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Ookla - Introducing a Better Measure of Latency

[Sebastian Moeller]

Hi Christoph,

nice! Thanks for posting.


For Android (and iOS) Ookla's speedtest app now reports a "Detailed result" page which contains:
1) Upload and download rates (albeit without information what exactly was measured) 
2) Data volume used per direction (but not the precise duration of the test)
3) Idle, download, upload responsiveness measures:
(probably) the average, the jitter, the minimum, and the maximum
4) Packet loss percentage

This is quite an improvement and achievement! I would wish for a bit more information about the details, like how was latency exactly measured, how many probes were used per direction and what are the individual delay values...

Unfortunately, the macos client seems not yet updated and the web based test also still only reports the idle RTT. I hope it is only a matter of time for those to be updated.

Regards
	Sebastian




> On May 12, 2022, at 19:15, Christoph Paasch via Bloat <bloat@lists.bufferbloat.net> wrote:
> 
> Ookla's measure of "loaded latency":
> 
> https://www.ookla.com/articles/introducing-loaded-latency
> 
> This will hopefully be a shift in how operators approach the bufferbloat problem.
> 
> 
> Christoph
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Ookla - Introducing a Better Measure of Latency

[Klatsky, Carl]

Its good that they are running the latency test also during the load test, but from what it looks like, they seem to be running the latency test to the same server as the load test.  I think a more realistic test is to run the load test to one server and the latency test to a different server.  That's a more realistic use case...

Regards,
Carl Klatsky

-----Original Message-----
From: Bloat <bloat-bounces@lists.bufferbloat.net> On Behalf Of Christoph Paasch via Bloat
Sent: Thursday, May 12, 2022 4:01 PM
To: nichols@pollere.net
Cc: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] Ookla - Introducing a Better Measure of Latency

I'm not aware of any rigorous study. But, just from the code, I know ICMP ping in many cases has a different traffic-class and thus implicitly gets quite a different treatment than real traffic.

However, Ookla uses TCP (port 8080) to probe the latency in their app.


Christoph

> On May 12, 2022, at 12:44 PM, Kathleen Nichols <nichols@pollere.net> wrote:
>
> a ping by any other name...
>
> Has anyone ever done a rigorous study to see how well ping delays correspond to the delay that information-carrying packets experience?
>
> On 5/12/22 10:15 AM, Christoph Paasch via Bloat wrote:
>> Ookla's measure of "loaded latency":
>> https://urldefense.com/v3/__https://www.ookla.com/articles/introducin
>> g-loaded-latency__;!!CQl3mcHX2A!DHnGDBw2sqsRwHiidAQUOhjXEavZmBOtJKb_IzPhxMm2vqUPyRC2pkVnScJId_KdaNVLsOS7sD0E8QRQ0m8B7LqBavY$  <https://urldefense.com/v3/__https://www.ookla.com/articles/introducing-loaded-latency__;!!CQl3mcHX2A!DHnGDBw2sqsRwHiidAQUOhjXEavZmBOtJKb_IzPhxMm2vqUPyRC2pkVnScJId_KdaNVLsOS7sD0E8QRQ0m8B7LqBavY$ > This will hopefully be a shift in how operators approach the bufferbloat problem.
>> Christoph
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://urldefense.com/v3/__https://lists.bufferbloat.net/listinfo/bl
>> oat__;!!CQl3mcHX2A!DHnGDBw2sqsRwHiidAQUOhjXEavZmBOtJKb_IzPhxMm2vqUPyR
>> C2pkVnScJId_KdaNVLsOS7sD0E8QRQ0m8BllXPjdw$
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://urldefense.com/v3/__https://lists.bufferbloat.net/listinfo/blo
> at__;!!CQl3mcHX2A!DHnGDBw2sqsRwHiidAQUOhjXEavZmBOtJKb_IzPhxMm2vqUPyRC2
> pkVnScJId_KdaNVLsOS7sD0E8QRQ0m8BllXPjdw$

_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://urldefense.com/v3/__https://lists.bufferbloat.net/listinfo/bloat__;!!CQl3mcHX2A!DHnGDBw2sqsRwHiidAQUOhjXEavZmBOtJKb_IzPhxMm2vqUPyRC2pkVnScJId_KdaNVLsOS7sD0E8QRQ0m8BllXPjdw$

Re: [Bloat] [Rpm] Ookla - Introducing a Better Measure of Latency

[Rich Brown]

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

This is very cool! I'm glad to see them embrace "download ping" and "upload ping". 

> On May 12, 2022, at 1:15 PM, Christoph Paasch via Rpm <rpm@lists.bufferbloat.net> wrote:
> 
> Ookla's measure of "loaded latency":
> 
> https://www.ookla.com/articles/introducing-loaded-latency <https://www.ookla.com/articles/introducing-loaded-latency>
> 
> This will hopefully be a shift in how operators approach the bufferbloat problem.
> 
> 
> Christoph
> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm


[-- Attachment #2: Type: text/html, Size: 1428 bytes --]

Re: [Bloat] Ookla - Introducing a Better Measure of Latency

[Sebastian Moeller]

Hi Carl,


> On May 12, 2022, at 23:04, Klatsky, Carl via Bloat <bloat@lists.bufferbloat.net> wrote:
> 
> Its good that they are running the latency test also during the load test, but from what it looks like, they seem to be running the latency test to the same server as the load test.  I think a more realistic test is to run the load test to one server and the latency test to a different server.  That's a more realistic use case...

	The question boils down to what "latency-under-load" should be measured here:
a) latency of different flows/hosts
b) latency of the load bearing flow(s)

both are informative, but if I had to choose I would ask Ookla for b), because running mtr/gping in parallel to a speedtest is comparatively easy compared to post-hoc deducing latency in the load bearing connection*... (I would assume that from a packet capture one might be able to piece this together when looking at the delay between sending a segment and receiving that matching ACK, which is more hassle than running e.g. "mtr -ezb4 --order LSNBAWVJMXI 8.8.8.8" ;) ) 

Regards
	Sebastian


*) Well, there are pping (https://github.com/pollere/pping) and DlyLoc (https://github.com/pollere/DlyLoc), but so far I have not tried to make these run on my router (probably should start on an endhost first).


> 
> Regards,
> Carl Klatsky
> 
> -----Original Message-----
> From: Bloat <bloat-bounces@lists.bufferbloat.net> On Behalf Of Christoph Paasch via Bloat
> Sent: Thursday, May 12, 2022 4:01 PM
> To: nichols@pollere.net
> Cc: bloat@lists.bufferbloat.net
> Subject: Re: [Bloat] Ookla - Introducing a Better Measure of Latency
> 
> I'm not aware of any rigorous study. But, just from the code, I know ICMP ping in many cases has a different traffic-class and thus implicitly gets quite a different treatment than real traffic.
> 
> However, Ookla uses TCP (port 8080) to probe the latency in their app.
> 
> 
> Christoph
> 
>> On May 12, 2022, at 12:44 PM, Kathleen Nichols <nichols@pollere.net> wrote:
>> 
>> a ping by any other name...
>> 
>> Has anyone ever done a rigorous study to see how well ping delays correspond to the delay that information-carrying packets experience?
>> 
>> On 5/12/22 10:15 AM, Christoph Paasch via Bloat wrote:
>>> Ookla's measure of "loaded latency":
>>> https://urldefense.com/v3/__https://www.ookla.com/articles/introducin
>>> g-loaded-latency__;!!CQl3mcHX2A!DHnGDBw2sqsRwHiidAQUOhjXEavZmBOtJKb_IzPhxMm2vqUPyRC2pkVnScJId_KdaNVLsOS7sD0E8QRQ0m8B7LqBavY$  <https://urldefense.com/v3/__https://www.ookla.com/articles/introducing-loaded-latency__;!!CQl3mcHX2A!DHnGDBw2sqsRwHiidAQUOhjXEavZmBOtJKb_IzPhxMm2vqUPyRC2pkVnScJId_KdaNVLsOS7sD0E8QRQ0m8B7LqBavY$ > This will hopefully be a shift in how operators approach the bufferbloat problem.
>>> Christoph
>>> _______________________________________________
>>> Bloat mailing list
>>> Bloat@lists.bufferbloat.net
>>> https://urldefense.com/v3/__https://lists.bufferbloat.net/listinfo/bl
>>> oat__;!!CQl3mcHX2A!DHnGDBw2sqsRwHiidAQUOhjXEavZmBOtJKb_IzPhxMm2vqUPyR
>>> C2pkVnScJId_KdaNVLsOS7sD0E8QRQ0m8BllXPjdw$
>> 
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://urldefense.com/v3/__https://lists.bufferbloat.net/listinfo/blo
>> at__;!!CQl3mcHX2A!DHnGDBw2sqsRwHiidAQUOhjXEavZmBOtJKb_IzPhxMm2vqUPyRC2
>> pkVnScJId_KdaNVLsOS7sD0E8QRQ0m8BllXPjdw$
> 
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://urldefense.com/v3/__https://lists.bufferbloat.net/listinfo/bloat__;!!CQl3mcHX2A!DHnGDBw2sqsRwHiidAQUOhjXEavZmBOtJKb_IzPhxMm2vqUPyRC2pkVnScJId_KdaNVLsOS7sD0E8QRQ0m8BllXPjdw$
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Ookla - Introducing a Better Measure of Latency

[Christoph Paasch]

[-- Attachment #1: Type: text/plain, Size: 4327 bytes --]

+1 on measuring the latency on the load-generating connections.


Christoph

> On May 13, 2022, at 12:48 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
> 
> Hi Carl,
> 
> 
>> On May 12, 2022, at 23:04, Klatsky, Carl via Bloat <bloat@lists.bufferbloat.net <mailto:bloat@lists.bufferbloat.net>> wrote:
>> 
>> Its good that they are running the latency test also during the load test, but from what it looks like, they seem to be running the latency test to the same server as the load test. I think a more realistic test is to run the load test to one server and the latency test to a different server. That's a more realistic use case...
> 
> 	The question boils down to what "latency-under-load" should be measured here:
> a) latency of different flows/hosts
> b) latency of the load bearing flow(s)
> 
> both are informative, but if I had to choose I would ask Ookla for b), because running mtr/gping in parallel to a speedtest is comparatively easy compared to post-hoc deducing latency in the load bearing connection*... (I would assume that from a packet capture one might be able to piece this together when looking at the delay between sending a segment and receiving that matching ACK, which is more hassle than running e.g. "mtr -ezb4 --order LSNBAWVJMXI 8.8.8.8" ;) ) 
> 
> Regards
> 	Sebastian
> 
> 
> *) Well, there are pping (https://github.com/pollere/pping <https://github.com/pollere/pping>) and DlyLoc (https://github.com/pollere/DlyLoc <https://github.com/pollere/DlyLoc>), but so far I have not tried to make these run on my router (probably should start on an endhost first).
> 
> 
>> 
>> Regards,
>> Carl Klatsky
>> 
>> -----Original Message-----
>> From: Bloat <bloat-bounces@lists.bufferbloat.net> On Behalf Of Christoph Paasch via Bloat
>> Sent: Thursday, May 12, 2022 4:01 PM
>> To: nichols@pollere.net
>> Cc: bloat@lists.bufferbloat.net
>> Subject: Re: [Bloat] Ookla - Introducing a Better Measure of Latency
>> 
>> I'm not aware of any rigorous study. But, just from the code, I know ICMP ping in many cases has a different traffic-class and thus implicitly gets quite a different treatment than real traffic.
>> 
>> However, Ookla uses TCP (port 8080) to probe the latency in their app.
>> 
>> 
>> Christoph
>> 
>>> On May 12, 2022, at 12:44 PM, Kathleen Nichols <nichols@pollere.net> wrote:
>>> 
>>> a ping by any other name...
>>> 
>>> Has anyone ever done a rigorous study to see how well ping delays correspond to the delay that information-carrying packets experience?
>>> 
>>> On 5/12/22 10:15 AM, Christoph Paasch via Bloat wrote:
>>>> Ookla's measure of "loaded latency":
>>>> https://urldefense.com/v3/__https://www.ookla.com/articles/introducin
>>>> g-loaded-latency__;!!CQl3mcHX2A!DHnGDBw2sqsRwHiidAQUOhjXEavZmBOtJKb_IzPhxMm2vqUPyRC2pkVnScJId_KdaNVLsOS7sD0E8QRQ0m8B7LqBavY$ <https://urldefense.com/v3/__https://www.ookla.com/articles/introducing-loaded-latency__;!!CQl3mcHX2A!DHnGDBw2sqsRwHiidAQUOhjXEavZmBOtJKb_IzPhxMm2vqUPyRC2pkVnScJId_KdaNVLsOS7sD0E8QRQ0m8B7LqBavY$ > This will hopefully be a shift in how operators approach the bufferbloat problem.
>>>> Christoph
>>>> _______________________________________________
>>>> Bloat mailing list
>>>> Bloat@lists.bufferbloat.net
>>>> https://urldefense.com/v3/__https://lists.bufferbloat.net/listinfo/bl
>>>> oat__;!!CQl3mcHX2A!DHnGDBw2sqsRwHiidAQUOhjXEavZmBOtJKb_IzPhxMm2vqUPyR
>>>> C2pkVnScJId_KdaNVLsOS7sD0E8QRQ0m8BllXPjdw$
>>> 
>>> _______________________________________________
>>> Bloat mailing list
>>> Bloat@lists.bufferbloat.net
>>> https://urldefense.com/v3/__https://lists.bufferbloat.net/listinfo/blo
>>> at__;!!CQl3mcHX2A!DHnGDBw2sqsRwHiidAQUOhjXEavZmBOtJKb_IzPhxMm2vqUPyRC2
>>> pkVnScJId_KdaNVLsOS7sD0E8QRQ0m8BllXPjdw$
>> 
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://urldefense.com/v3/__https://lists.bufferbloat.net/listinfo/bloat__;!!CQl3mcHX2A!DHnGDBw2sqsRwHiidAQUOhjXEavZmBOtJKb_IzPhxMm2vqUPyRC2pkVnScJId_KdaNVLsOS7sD0E8QRQ0m8BllXPjdw$
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net <mailto:Bloat@lists.bufferbloat.net>
>> https://lists.bufferbloat.net/listinfo/bloat <https://lists.bufferbloat.net/listinfo/bloat>

[-- Attachment #2: Type: text/html, Size: 17635 bytes --]