Re: [Bloat] this explains speedtest stuff

[Dave Taht <dave.taht@gmail.com>]

On Sat, Apr 25, 2020 at 8:59 AM Kenneth Porter <shiva@sewingwitch.com> wrote:
>
> On 4/25/2020 8:43 AM, Dave Taht wrote:
> > and the last flaw of this test series is that ken took the dslreports
> > "fiber" setting for the dslreports test as "The right thing". the
> > "fiber" test is structured to stress test an asymmetric 1gbit/100mbit
> > connection, not a shaped fiber connection running at 50mbit symmetric.
> > The number of uploads is 4, downloads, 32.... it's totally ok to pick
> > a given fiber/cable/whatever test, but it does help to apply the same
> > characteristics to more of the tests you do, if you are trying to
> > compare technologies.
>
> I'd be happy to test with a different set of speed test settings. Would
> Corporate/Edu be a better choice?

Sticking with the fiber test is ok, though I wish it tried more upload flows.

There is a "hires bufferbloat" option in the dslreports settings that
I find useful.

>
> In going through this exercise, I can imagine someone saying "where'd
> all the bandwidth I paid for go?" as we trade bandwidth for reduced
> latency. How do you sell that to end users? ISPs have trained people to
> think only in terms of raw speed (obviously that's best for an ISP's
> bottom line as they can upsell you the higher-priced package) and most
> people (outside of gamers) don't really grasp latency with the
> intuitiveness of speed. Maybe we need some Youtube videos showing end
> user experiences of the benefit of reduced latency.

You didn't lose anything really on the upload. the wild swings of
throughput with such an overbuffered link balance
out with the relative smoothness inherent in fq_codel, and eliminating
the side effects of other users of the link
is really wonderful (partially why I wanted to see cake in this environment)

on the download, yea, you lost a bit there, but also got rid of wild
swings of throughput, and things like dns
will always just "fly" which IMHO is the biggest bottleneck for most
web pages. Caching your corporate dns locally
if at all possible might help a bit, but kind of difficult to do
right. Worse, most openvpn implementations I've seen
tend to route *all traffic* through it, rather than intelligently
using local resources for stuff outside the vpn.

most users ALSO don't run speedtest, either. They just want things to
work, and some tiny percentage difference
in perceived slowness of download speed they won't notice. jitter and
voip/video glitches far more apparent to most users.
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729