Re: [Bloat] an observation from the field

[Jonathan Foulkes <jf@jonathanfoulkes.com>]

Dave, very interesting to hear. In my dataset, I find that non-technical users respond positively to the benefits of low-latency, even if the speedtest metrics show much lower numbers than their plan indicates. Stuff happens quicker, and more consistently,  therefore they are happy.

It’s the semi-techies and hard-core geeks that are a challenge, as they insist on getting the ‘speed’ they pay for, and no amount of explaining satisfies them.

Interestingly, we see some 200+ Mbps lines that show low bloat on the inbound leg with QoS off during tests, but if QoS is left disabled, speed is high, but real-world use suffers and QoS has to be reinstated on the inbound path. Seems the transient bloat on these lines affects usability to the point where users will now accept lower throughput in exchange for goodput.
We see this mainly on Cable systems, not so much on (well deployed) fiber.

I see the challenge as needing to continue to socialize the benefits of low latency vs capacity to the tech crowd. And I still think we need a good end-user accessible test that would prove that point in a way non-techies would get.

Cheers,

Jonathan Foulkes
CEO - Evenroute.com

> On Aug 28, 2018, at 1:07 PM, Dave Taht <dave.taht@gmail.com> wrote:
> 
> In looking over the increasingly vast sqm-related deployment, there's
> a persistent data point that pops up regarding inbound shaping at high
> rates.
> 
> We give users a choice - run out of cpu at those rates or do inbound
> sqm at a rate their cpu can afford.  A remarkable percentage are
> willing to give up tons of bandwidth in order to avoid latency
> excursions (oft measured, even in these higher speed 200+Mbit
> deployments, in the 100s of ms) -
> 
> At least some users want low delay always. It's just the theorists
> that want high utilization right at the edge of capacity. Users are
> forgiving about running out of cpu - disgruntled, but forgiving.
> 
> Certainly I'm back at the point of recommending tbf+fq_codel for
> inbound shaping at higher rates - and looking at restoring the high
> speed version of cake - and I keep thinking a better policer is
> feasible.
> 
> -- 
> 
> Dave Täht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat