[LibreQoS] ookla speedtest results?

Mon Oct 24 13:34:56 EDT 2022

> Presently (in v1.3.), robert (in grafina?) is summing drops + marks.
which is a good idea, however perhaps drops, marks and drops+marks
would be better.

Yup, in InfluxDB for the stats by Tin (diffserv4) we display true drops as
(trueDrops = ecn_mark + drops - ack_drops). But we don't do it by sub quite
yet.
And ok, drops, marks and drops+marks can be shown instead - by subscriber
or by Node (AP/Site).
Dave - is it ok if we graph this data as a percentage of packets sent? So
for drops, drop / sent_packets ? I just imagine that  would make comparing
different subscribers' connections easier.

Question for all - is having drops / marks/ drops+marks by
subscriber/circuit worth the extra modest InfluxDB CPU use? Or should we
just show those stats by AP/Node?
If preseem currently offers such stats at a subscriber level we can do the
same, just wanna be sure I'm not overtaxing CPU.

On Mon, Oct 24, 2022 at 11:14 AM Dave Taht via LibreQoS <
libreqos at lists.bufferbloat.net> wrote:

> Some of the context of my request for libreqos on vs off is from here,
> presentation in the wee hours, wed morning.
>
> https://www.linkedin.com/feed/update/urn:li:activity:6989281945868283904/
>
> On Mon, Oct 24, 2022 at 9:48 AM dan via LibreQoS
> <libreqos at lists.bufferbloat.net> wrote:
> >
> > we also have a bunch of 25/5.  It would be nice to get some more
> detailed numbers from ookla tests.
>
> +1! We've argued methods with many a provider, and ookla and samknows
> are new to this game.
>
> As one example I don't know if they use decimal or binary mbits!
>
> ...
>
> ack-filtering in the libreqos case can and will drop acks in both
> directions, due to the structure of how htb
> works in this scenario, at any bandwidth ratio. I *think* it does very
> little harm but I would use the ack-filter
> not the aggressive ack filter out of caution.
>
> Secondly if you are gathering drop statistics from the higher level
> htb categories, total drops will go WAY up,
> and it is best to use the cake drop, ack_drop outputs statistics directly.
>
> ack_drops have nothing to do with congestion control and should be
> ignored in most cases.
>
> Also I keep hoping more will pull out ecn marks separately. Public use
> is way up by e2e transports, and I worry that a high ecn ratio is a
> e2e network error, which might show up as a big backlog.
>
> Presently (in v1.3.), robert (in grafina?) is summing drops + marks.
> which is a good idea, however perhaps drops, marks and drops+marks
> would be better.
>
> An inverse log scale is needed to plot marks, drops, and ack_drops.
>
> I'll always be of the opinion that it's best to run cake on egress at
> the cpe, first, doing all this work before it hits the wire.
> Are any of you doing that? Openwrt/dd-wrt/firewalla/mikrotik 7.2?
>
> >We also have a lot of Eero units out there, so watching for the eero
> speed test would also be great.
>
> eero 5s have cake (and fq_codel on the wifi), eero 6s have a somewhat
> buggy fq_codel offload:
>
>
> https://www.reddit.com/r/eero/comments/u7xm83/gen_2_sqm_vs_gen_3_sqm_stick_with_gen_2_if_you/
> > On Mon, Oct 24, 2022 at 10:31 AM Herbert Wolverson via LibreQoS <
> libreqos at lists.bufferbloat.net> wrote:
> >>
> >> > sniff DNS for those speed test lookups and trigger a packet capture
> for x duration?
> >>
> >> That's a good idea (I think there's a service somewhere for finding
> speedtest
> >> servers?). We're discussing testing the ack-filter feature right now,
> and something
> >> similar would work well for that. (We have a bunch of 25/5 and
> similarly asymmetric
> >> connections, in theory it'll help...)
> >>
> >> On Mon, Oct 24, 2022 at 10:31 AM dan via LibreQoS <
> libreqos at lists.bufferbloat.net> wrote:
> >>>
> >>> sniff DNS for those speed test lookups and trigger a packet capture
> for x duration?
> >>>
> >>> On Mon, Oct 24, 2022 at 9:27 AM Dave Taht <dave.taht at gmail.com> wrote:
> >>>>
> >>>> On Mon, Oct 24, 2022 at 8:20 AM dan <dandenson at gmail.com> wrote:
> >>>> >
> >>>> > Dave, I think that 'bouncing' is more CPU time in the browser.  I
> don't think it's indicative over what's actually happening.
> >>>>
> >>>> A simultaneous packet capture and wireshark plot of the RTTs would
> >>>> also be helpful.
> >>>>
> >>>> >
> >>>> > On Mon, Oct 24, 2022 at 9:09 AM Dave Taht via LibreQoS <
> libreqos at lists.bufferbloat.net> wrote:
> >>>> >>
> >>>> >> On Mon, Oct 24, 2022 at 8:02 AM Robert Chacón via LibreQoS
> >>>> >> <libreqos at lists.bufferbloat.net> wrote:
> >>>> >> >
> >>>> >> > I can run an Ookla test in the middle of the night with LibreQoS
> off for a bit.
> >>>> >>
> >>>> >> Groovy.
> >>>> >>
> >>>> >> > From what I recall - without Libre we see download bloat of
> 300ms or so. With Libre, it's gone. On waveform we see 0ms added bloat each
> direction for most clients.
> >>>> >>
> >>>> >> The numbers report by speedtest bounce around a lot, and they tend
> to
> >>>> >> pick a lower number as a final result than I'd
> >>>> >> like. If there's a way to capture a movie of it...
> >>>> >> >
> >>>> >> > And I like the "monitor only" mode idea.
> >>>> >> > Perhaps we could create the HTB tree, but just not attach the
> CAKE qdisc?
> >>>> >> > Technically even HTB could reduce latency by itself on
> overloaded APs , so it wouldn't be true passive monitoring, but it would
> allow us to compare the before/after of CAKE while still having qdiscs we
> can point cpumap-pping to.
> >>>> >> >
> >>>> >> > Alternatively, maybe we could use eBPF PPing just for this
> passive monitoring period?
> >>>> >> >
> >>>> >> >
> >>>> >> > On Mon, Oct 24, 2022 at 8:02 AM Herbert Wolverson via LibreQoS <
> libreqos at lists.bufferbloat.net> wrote:
> >>>> >> >>
> >>>> >> >> Are you looking for a shaped result? That'll show "whatever
> bandwidth
> >>>> >> >> is left on the sector" without Libre, and around the customer's
> paid-for
> >>>> >> >> target with Libre (hopefully!).
> >>>> >> >>
> >>>> >> >> One thing Preseem does well is that their onboarding process
> includes
> >>>> >> >> "leave it in monitoring-only mode" for a week, gathering data
> before you
> >>>> >> >> pull the switch (although most ISPs I've talked to just pull
> the switch...)
> >>>> >> >> It's quite enlightening to see a before/after, even with only
> FQ_CODEL
> >>>> >> >> as the shaper.
> >>>> >> >>
> >>>> >> >> We could probably do something similar with a "monitor only"
> mode that
> >>>> >> >> doesn't enable any queues (is there a TC equivalent to "dummy"
> on
> >>>> >> >> FreeBSD?).
> >>>> >> >>
> >>>> >> >> On Mon, Oct 24, 2022 at 8:52 AM Dave Taht via LibreQoS <
> libreqos at lists.bufferbloat.net> wrote:
> >>>> >> >>>
> >>>> >> >>> I am curious if anyone here has speedtest results with
> libreqos on and
> >>>> >> >>> off, and can send a screen shot?
> >>>> >> >>>
> >>>> >> >>> --
> >>>> >> >>> This song goes out to all the folk that thought Stadia would
> work:
> >>>> >> >>>
> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
> >>>> >> >>> Dave Täht CEO, TekLibre, LLC
> >>>> >> >>> _______________________________________________
> >>>> >> >>> LibreQoS mailing list
> >>>> >> >>> LibreQoS at lists.bufferbloat.net
> >>>> >> >>> https://lists.bufferbloat.net/listinfo/libreqos
> >>>> >> >>
> >>>> >> >> _______________________________________________
> >>>> >> >> LibreQoS mailing list
> >>>> >> >> LibreQoS at lists.bufferbloat.net
> >>>> >> >> https://lists.bufferbloat.net/listinfo/libreqos
> >>>> >> >
> >>>> >> >
> >>>> >> >
> >>>> >> > --
> >>>> >> > Robert Chacón
> >>>> >> > CEO | JackRabbit Wireless LLC
> >>>> >> > _______________________________________________
> >>>> >> > LibreQoS mailing list
> >>>> >> > LibreQoS at lists.bufferbloat.net
> >>>> >> > https://lists.bufferbloat.net/listinfo/libreqos
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >> --
> >>>> >> This song goes out to all the folk that thought Stadia would work:
> >>>> >>
> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
> >>>> >> Dave Täht CEO, TekLibre, LLC
> >>>> >> _______________________________________________
> >>>> >> LibreQoS mailing list
> >>>> >> LibreQoS at lists.bufferbloat.net
> >>>> >> https://lists.bufferbloat.net/listinfo/libreqos
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> This song goes out to all the folk that thought Stadia would work:
> >>>>
> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
> >>>> Dave Täht CEO, TekLibre, LLC
> >>>
> >>> _______________________________________________
> >>> LibreQoS mailing list
> >>> LibreQoS at lists.bufferbloat.net
> >>> https://lists.bufferbloat.net/listinfo/libreqos
> >>
> >> _______________________________________________
> >> LibreQoS mailing list
> >> LibreQoS at lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/libreqos
> >
> > _______________________________________________
> > LibreQoS mailing list
> > LibreQoS at lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/libreqos
>
>
>
> --
> This song goes out to all the folk that thought Stadia would work:
>
> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
> Dave Täht CEO, TekLibre, LLC
> _______________________________________________
> LibreQoS mailing list
> LibreQoS at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/libreqos
>

-- 
Robert Chacón
CEO | JackRabbit Wireless LLC <http://jackrabbitwireless.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/libreqos/attachments/20221024/6fc6ec9e/attachment.html>