Sergey - I wasn't assuming anything about fast.com. The document you shared
wasn't clear about the methodology's details here. Others sadly, have actually
used ICMP pings in the way I described. I was making a generic comment of
concern.
That said, it sounds like what you are doing is really
Hi David,
in principle I agree, a NATed IPv4 ICMP probe will be at best reflected at the
NAT router (CPE) (some commercial home gateways do not respond to ICMP echo
requests in the name of security theatre). So it is pretty hard to measure the
full end to end path in that configuration. I
--- Begin Message ---
Dave, thanks for sharing interesting thoughts and context.
> I am still a bit worried about properly defining "latency under load" for
> a NAT routed situation. If the test is based on ICMP Ping packets *from the
> server*, it will NOT be measuring the full path latency,
I am still a bit worried about properly defining "latency under load" for a NAT
routed situation. If the test is based on ICMP Ping packets *from the server*,
it will NOT be measuring the full path latency, and if the potential congestion
is in the uplink path from the access provider's
On Sat, May 2, 2020 at 9:37 AM Benjamin Cronce wrote:
>
> > Fast.com reports my unloaded latency as 4ms, my loaded latency as ~7ms
I guess one of my questions is that with a switch to BBR netflix is
going to do pretty well. If fast.com is using bbr, well... that
excludes much of the current side
> Fast.com reports my unloaded latency as 4ms, my loaded latency as ~7ms
For download, I show 6ms unloaded and 6-7 loaded. But for upload the loaded
shows as 7-8 and I see it blip upwards of 12ms. But I am no longer using
any traffic shaping. Any anti-bufferbloat is from my ISP. A graph of the
Michael Richardson :
> Does it find/use my nearest Netflix cache?
Thankfully, it appears so. The DSLReports bloat test was interesting, but
the jitter on the ~240ms base latency from South Africa (and other parts of
the world) was significant enough that the figures returned were often
