Matthew Ford writes:
> What's the bufferbloat verdict on https://speed.cloudflare.com/ ?
Huh, didn't know about that. Seems they're measuring the latency before
the download test, though, so no bufferbloat numbers. If anyone knows
someone at Cloudflare we could try to bug to get this fixed,
Hi Sergey,
> On May 4, 2020, at 19:04, Sergey Fedorov wrote:
>
> 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
>
Dear David,
Thanks for the elaboration below, and indeed I was not appreciating the full
scope of the challenge.
> On May 3, 2020, at 17:06, David P. Reed wrote:
>
> Thanks Sebastian. I do agree that in many cases, reflecting the ICMP off the
> entry device that has the external IP address
I think the real test should be multiple clients, not multiple sources, but
coordinating is hard. The middleboxes on the way may treat distinct IP host
addresses specially, and of course there is an edge case because a single NIC
by definition never sends two datagrams at once, which distort
;
> Bcc:
> Date: Mon, 4 May 2020 10:04:19 -0700
> Subject: Re: [Cake] [Make-wifi-fast] [Bloat] dslreports is no longer free
>
>> Sergey - I wasn't assuming anything about fast.com. The document you
>> shared wasn't clear about the methodology's details here. Others sadly,
&g
--- Begin Message ---
>
> 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
Thanks Sebastian. I do agree that in many cases, reflecting the ICMP off the
entry device that has the external IP address for the NAT gets most of the RTT
measure, and if there's no queueing built up in the NAT device, that's a
reasonable measure. But...
However, if the router has "taken up
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
14 matches
Mail list logo
