I recommend dslreports.com/speedtest these days (was Speedtest.net not accessible in Chrome due to deceptive ads)

Jim Gettys jg at freedesktop.org
Wed Jul 27 00:26:04 UTC 2016


Some additional comments from Dave Taht, who does not subscribe to the
nanog list.  Also note the early WiFi results, which are spectacular.  Your
customers will have bufferbloat both due to the ISP, and due to the WiFi
hop that is usually between them and their home router.  Unfortunately,
it's going to take years for the WiFi fixes to percolate through the
ecosystem, which is very dysfunctional (it's taken about 4 years to see
Docsis 3.1 modems, which are only now appearing).
                                                        - Jim

If you would like to see a plot of all the millions of samples
dslreports collected to date on the endemic bufferbloat along the edge
of the internet, as well as breakdowns by ISPs, see:

uploads: http://www.dslreports.com/speedtest/results/bufferbloat?up=1

downloads: http://www.dslreports.com/speedtest/results/bufferbloat

And look at the sea of stuff with latencies measured in the hundreds of
ms...
and get up off your ass and do something about it on your networks.

It's easy now.

The algorithms we've developed to fix it (fq_codel, pie) are in bsd,
and linux now; the ietf drafts are complete. These algorithms can move
induced latencies to well below 30ms in most cases, on ethernet, dsl,
cable, and fiber. fq_codel has been out there since 2012. A goodly
percentage of linux distros now defaults to fq_codel, but doing up the
chokepoints right involves replacing old shapers and policers with
these algorithms, additionally. See the "sqm-scripts" for how.

... side note ...


Fixing wifi with similar stuff has proven *very* difficult, but we've
made quite a bit of progress lately in the ath10k and ath9k chipsets,
that is not quite ready for prime time: pretty exciting summary, here:

https://blog.tohojo.dk/2016/06/fixing-the-wifi-performance-anomaly-on-ath9k.html



On Fri, Jul 22, 2016 at 4:31 PM, Jim Gettys <jg at freedesktop.org> wrote:

>
>
> On Fri, Jul 22, 2016 at 4:18 PM, Baldur Norddahl <
> baldur.norddahl at gmail.com> wrote:
>
>> Den 22. jul. 2016 21.34 skrev "Jim Gettys" <jg at freedesktop.org>:
>> >
>> >
>> > So it is entirely appropriate in my view to give even "high speed"
>> > connections low grades; it's telling you that they suck under load
>> > ​, like when your kid is downloading a video (or uploading one for their
>> > friends); your performance (e.g. web surfing) can go to hell in a
>> > hand-basket despite having a lot of bandwidth on the
>> > connection. For most use, I'll take a 20Mbps link without bloat to a
>> > 200Mbps one with a half second of bloat any
>> > ​ ​
>> > day.
>> > ​
>>
>> I will expect that high speed links will have little bloat simply because
>> even large buffers empty quite fast.
>>
>
> ​Unfortunately, that is often/usually not the case.​
>
> ​  The buffering has typically scaled up as fast/faster than the bandwidth
> has, in my observation. You can have as much/more bloat on a higher
> bandwidth line as a low bandwidth line.
>
> That's why I always refer to buffering in seconds​, not bytes, unless I'm
> trying to understand how the identical equipment will behave at differing
> bandwidths.
>
> The worst is usually someone taking modern equipment and then running it
> at low speed: e.g. a gigabit switch being used at 100Mbps will generally be
> 10x worse than the old equipment it replaces (at best).
>
>                      - Jim
>
>



More information about the NANOG mailing list