From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 0ABC53B29E for ; Mon, 24 Oct 2022 14:06:49 -0400 (EDT) Received: by mail-pl1-x630.google.com with SMTP id d24so9130877pls.4 for ; Mon, 24 Oct 2022 11:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=dfZZIUwBt/XJHzarxsHk6Gx47upTtpbc1rpov9lT2wY=; b=e0HcnOwj/l9lVL2CxCFWAJTzGEOJzUVAskheQNF54XRsYNVSpFVuGp0ENkSCemnBlA YgyTBlqXZdGZsZ7GJeNetsJ/dC3k7vYh1A8b4PoBXPGyXDRg+OLsFBXl0DgmPrYj3NZQ GQ93Xwamub26stytPRLkx1MAWVDCmc8KhoQSq9yDTfdfmfMc+r2WcWz9EwjMB5uZ+6Pg ez95FeGDedub6rnoYABnu+BWxRAxqKNrC5xBuWRLBchm4GSfkBeSGgHOr1I1LDB8YcpR zq8w1/wsVuVAgd2jWsmWqswXTuUmsMUjX2oAtks8mZlNTT4U6ON+cBZ/tx9OyhulNEmF 1cxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dfZZIUwBt/XJHzarxsHk6Gx47upTtpbc1rpov9lT2wY=; b=XiSVbH4FNdsT31xaSZD0yBj1d7RyJiIpUpzIUlWDmjmB164pnyLKhUcNJdtayymrK2 aQgVgIq0hNaGyKjbGUgEwnOOUHY1GYPD7Z25vNIBAG4ak1fsbSx9FjuI1RtiT9yM35Li ky2b68Iv+9eGjAS5KcF7z1sPZX9VaA7GX2uFgEJftCLusUDr+kfEW7PnKNZgHhu0qYON UU32v9VwvAQeYle/2JHN4K00C5uqpq9WT8Y+SaBWqNfGMs2JCG0NGnRCqE20TV7gqXpu tfGf6EwAgIBojqup/JJUs+8jDP2QgnlQgBfWbHkETGC+5iPiu9V1TwD4Wshv8S90B+6c +FTA== X-Gm-Message-State: ACrzQf0ujLKy6ei88CuM0dREUGDIqUqRJM7LBBTb34HyHFcIaawkmuWX aeKPf/JFgCxen0UY/n7krShq0uNsV2tB1eH0QOBYFeCz X-Google-Smtp-Source: AMsMyM7t38pAVmSp6jes1IXQzYMDy9YhmqYGaNxjenBChAcbVc1ziSfswz+p7brvGw0ddFzBRhyOQfoLkRFsrDAcZ/M= X-Received: by 2002:a17:90b:4b0f:b0:211:41f:1c72 with SMTP id lx15-20020a17090b4b0f00b00211041f1c72mr30485371pjb.25.1666634808560; Mon, 24 Oct 2022 11:06:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Herbert Wolverson Date: Mon, 24 Oct 2022 13:06:38 -0500 Message-ID: Cc: libreqos@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="000000000000bc109105ebcba739" Subject: Re: [LibreQoS] ookla speedtest results? X-BeenThere: libreqos@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Many ISPs need the kinds of quality shaping cake can do List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2022 18:06:50 -0000 --000000000000bc109105ebcba739 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think we have a handful of HAP lite's left? They aren't great, but they are cheap - so we have a small apartment complex using them as client-side devices. The complex is a half-way house for paroled offenders, and they destroy a *lot* of hardware. :-| The biggest issue we've had (other than they aren't very resilient to someone who needs anger-management classes) is the antenna. There's just not a lot of gain there. On Mon, Oct 24, 2022 at 1:03 PM dan via LibreQoS < libreqos@lists.bufferbloat.net> wrote: > We're pretty far past that hardware. Minimum plans at most sites are now > 100x20 and we're moving rapidly to 200x200-1Gx1G plans. The implication > being that we need 4x4 AX wifi radios and that's real tough in an openwrt > compatible hardware right now, not a ton of options. > > Flat out though, wisps in general simply do not have the option of > controlling every client side router or even sending out new/compatible > routers for each customer to pull this off. It's a non-starter for us. > It may be better but it's just not an option that can be pursued. > ingress and egress edge shaping is what we need. > > On Mon, Oct 24, 2022 at 11:57 AM Dave Taht wrote: > >> On Mon, Oct 24, 2022 at 10:46 AM dan wrote: >> > >> > Some sort of % drop is better than count from an operator's >> perspective. I'm actually happy with 'scaling issues' of % on small vs >> large plan because those small plans are the one's we probably want to p= ush >> for upgrades if they're seeing a lot of drops. >> > >> > That said, a 'score' method works really well from a high level. And >> that can be proportionally adjusted so a slightly higher % in a small pl= an >> gives the same score as a larger plan would with fewer drops. >> > >> > >> > Also, on the SNMP statement above, we had the same issue with preseem >> being hyper aggressive to pull stats. Some mikrotik versions have some >> snmp flaws and preseem can peg the CPU. Hasn't happened in a while but >> that was an issue. >> >> I gave up on mikrotik long before they started working on routeros7, >> and just reflashed everything to openwrt. >> >> I have a nice little custom build for it assembled for the ubnt agws, >> and the mikrotik hap ac lite. Anyone using those? >> >> I would hope they don't have the snmp problem you describe, and if >> they did I could get it fixed in days. >> >> Vastly improved the wifi in particular, see before/after here: >> https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/59002/ >> >> (After about 40Mbits, the bloat starts moving to the wifi) >> >> Most of my work in the past 9 months has been on improving the >> mediatek mt76 derived products. I left off here: >> https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/59002/908 >> >> A lot of this stuff is shipping commercially in the openwifi project, >> if you haven't been paying attention to that. >> >> > On Mon, Oct 24, 2022 at 11:42 AM Dave Taht wrote= : >> >> >> >> On Mon, Oct 24, 2022 at 10:35 AM Robert Chac=C3=B3n >> >> wrote: >> >> > >> >> > > 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 =3D ecn_mark + drops - ack_drops). But we don't do i= t 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 mak= e >> comparing different subscribers' connections easier. >> >> >> >> Drops and marks are proportional to the plan. You get a heck of a lot >> >> more drops at 5mbits than 50, and the relationship >> >> is not linear, closer to quadratic. >> >> >> >> So comparing customers at their given tiers makes more sense than >> >> across the board. >> >> >> >> As for a percentage, you should see a clear difference in percentages >> >> across tiers. >> >> >> >> I know I'm not quite answering your question well, I'm a big believer >> >> in just getting lots of data, graphing it every which way, >> >> and seeing what's useful. >> >> >> >> > 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@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 >> >> >> 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 leve= l >> >> >> 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 + mark= s. >> >> >> 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_sti= ck_with_gen_2_if_you/ >> >> >> > On Mon, Oct 24, 2022 at 10:31 AM Herbert Wolverson via LibreQoS = < >> libreqos@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 righ= t >> 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@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 >> wrote: >> >> >> >>>> >> >> >> >>>> On Mon, Oct 24, 2022 at 8:20 AM dan >> 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@lists.bufferbloat.net> wrote: >> >> >> >>>> >> >> >> >> >>>> >> On Mon, Oct 24, 2022 at 8:02 AM Robert Chac=C3=B3n via Lib= reQoS >> >> >> >>>> >> 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 bloa= t >> 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 attac= h >> 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 w= e >> 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 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, gatherin= g >> 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 wit= h >> 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@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-69813666= 65607352320-FXtz >> >> >> >>>> >> >>> Dave T=C3=A4ht CEO, TekLibre, LLC >> >> >> >>>> >> >>> _______________________________________________ >> >> >> >>>> >> >>> LibreQoS mailing list >> >> >> >>>> >> >>> LibreQoS@lists.bufferbloat.net >> >> >> >>>> >> >>> https://lists.bufferbloat.net/listinfo/libreqos >> >> >> >>>> >> >> >> >> >> >>>> >> >> _______________________________________________ >> >> >> >>>> >> >> LibreQoS mailing list >> >> >> >>>> >> >> LibreQoS@lists.bufferbloat.net >> >> >> >>>> >> >> https://lists.bufferbloat.net/listinfo/libreqos >> >> >> >>>> >> > >> >> >> >>>> >> > >> >> >> >>>> >> > >> >> >> >>>> >> > -- >> >> >> >>>> >> > Robert Chac=C3=B3n >> >> >> >>>> >> > CEO | JackRabbit Wireless LLC >> >> >> >>>> >> > _______________________________________________ >> >> >> >>>> >> > LibreQoS mailing list >> >> >> >>>> >> > LibreQoS@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-69813666= 65607352320-FXtz >> >> >> >>>> >> Dave T=C3=A4ht CEO, TekLibre, LLC >> >> >> >>>> >> _______________________________________________ >> >> >> >>>> >> LibreQoS mailing list >> >> >> >>>> >> LibreQoS@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-69813666= 65607352320-FXtz >> >> >> >>>> Dave T=C3=A4ht CEO, TekLibre, LLC >> >> >> >>> >> >> >> >>> _______________________________________________ >> >> >> >>> LibreQoS mailing list >> >> >> >>> LibreQoS@lists.bufferbloat.net >> >> >> >>> https://lists.bufferbloat.net/listinfo/libreqos >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> LibreQoS mailing list >> >> >> >> LibreQoS@lists.bufferbloat.net >> >> >> >> https://lists.bufferbloat.net/listinfo/libreqos >> >> >> > >> >> >> > _______________________________________________ >> >> >> > LibreQoS mailing list >> >> >> > LibreQoS@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-69813666= 65607352320-FXtz >> >> >> Dave T=C3=A4ht CEO, TekLibre, LLC >> >> >> _______________________________________________ >> >> >> LibreQoS mailing list >> >> >> LibreQoS@lists.bufferbloat.net >> >> >> https://lists.bufferbloat.net/listinfo/libreqos >> >> > >> >> > >> >> > >> >> > -- >> >> > Robert Chac=C3=B3n >> >> > CEO | JackRabbit Wireless LLC >> >> >> >> >> >> >> >> -- >> >> This song goes out to all the folk that thought Stadia would work: >> >> >> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-69813666= 65607352320-FXtz >> >> Dave T=C3=A4ht CEO, TekLibre, LLC >> >> >> >> -- >> This song goes out to all the folk that thought Stadia would work: >> >> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-69813666= 65607352320-FXtz >> Dave T=C3=A4ht CEO, TekLibre, LLC >> > _______________________________________________ > LibreQoS mailing list > LibreQoS@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/libreqos > --000000000000bc109105ebcba739 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think we have a handful of HAP lite's left? The= y aren't great, but they are cheap - so
we have a small apart= ment complex using them as client-side devices. The
complex is a = half-way house for paroled offenders, and they destroy a *lot*
of= hardware. :-|

The biggest issue we've had (ot= her than they aren't very resilient to someone
who needs ange= r-management classes) is the antenna. There's just not a lot
= of gain there.

On Mon, Oct 24, 2022 at 1:03 PM dan via LibreQoS &l= t;libreqos@lists.bufferbl= oat.net> wrote:
We're pretty far past that hardware.=C2=A0 Mini= mum plans at most sites are now 100x20 and we're moving rapidly to 200x= 200-1Gx1G plans.=C2=A0 The implication being that we need 4x4 AX wifi radio= s and that's real tough in an openwrt compatible hardware right now, no= t a ton of options.=C2=A0

Flat out though, wisps in general simply d= o not have the option of controlling every client side router or even sendi= ng out new/compatible routers for each customer=C2=A0to pull this off.=C2= =A0 It's a non-starter for us.=C2=A0 =C2=A0 It may be better but it'= ;s just not an option that can be pursued.=C2=A0 ingress=C2=A0and egress=C2= =A0edge shaping is what we need.=C2=A0

=
On Mon, Oct 24, 2022 at 11:57 AM Dave= Taht <dave.tah= t@gmail.com> wrote:
On Mon, Oct 24, 2022 at 10:46 AM dan <dandenson@gmail.com> wrote:
>
> Some sort of % drop is better than count from an operator's perspe= ctive.=C2=A0 I'm actually happy with 'scaling issues' of % on s= mall vs large plan because those small plans are the one's we probably = want to push for upgrades if they're seeing a lot of drops.
>
> That said, a 'score' method works really well from a high leve= l.=C2=A0 And that can be proportionally adjusted so a slightly higher % in = a small plan gives the same score as a larger plan would with fewer drops.<= br> >
>
> Also, on the SNMP statement above, we had the same issue with preseem = being hyper aggressive to pull stats.=C2=A0 Some mikrotik versions have som= e snmp flaws and preseem can peg the CPU.=C2=A0 Hasn't happened in a wh= ile but that was an issue.

I gave up on mikrotik long before they started working on routeros7,
and just reflashed everything to openwrt.

I have a nice little custom build for it assembled for the ubnt agws,
and the mikrotik hap ac lite. Anyone using those?

I would hope they don't have the snmp problem you describe, and if
they did I could get it fixed in days.

Vastly improved the wifi in particular, see before/after here:
https://forum.openwrt.org/t/aql-and-t= he-ath10k-is-lovely/59002/

(After about 40Mbits, the bloat starts moving to the wifi)

Most of my work in the past 9 months has been on improving the
mediatek mt76 derived products. I left off here:
https://forum.openwrt.org/t/aql-an= d-the-ath10k-is-lovely/59002/908

A lot of this stuff is shipping commercially in the openwifi project,
if you haven't been paying attention to that.

> On Mon, Oct 24, 2022 at 11:42 AM Dave Taht <dave.taht@gmail.com> wrote:
>>
>> On Mon, Oct 24, 2022 at 10:35 AM Robert Chac=C3=B3n
>> <robert.chacon@jackrabbitwireless.com> wrote:
>> >
>> > > Presently (in v1.3.), robert (in grafina?) is summing dr= ops + 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 =3D 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 - b= y subscriber or by Node (AP/Site).
>> > Dave - is it ok if we graph this data as a percentage of pack= ets sent? So for drops, drop / sent_packets ? I just imagine that=C2=A0 wou= ld make comparing different subscribers' connections easier.
>>
>> Drops and marks are proportional to the plan. You get a heck of a = lot
>> more drops at 5mbits than 50, and the relationship
>> is not linear, closer to quadratic.
>>
>> So comparing customers at their given tiers makes more sense than<= br> >> across the board.
>>
>> As for a percentage, you should see a clear difference in percenta= ges
>> across tiers.
>>
>> I know I'm not quite answering your question well, I'm a b= ig believer
>> in just getting lots of data, graphing it every which way,
>> and seeing what's useful.
>>
>> > Question for all - is having drops / marks/ drops+marks by su= bscriber/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 <<= a href=3D"mailto:libreqos@lists.bufferbloat.net" target=3D"_blank">libreqos= @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://w= ww.linkedin.com/feed/update/urn:li:activity:6989281945868283904/
>> >>
>> >> On Mon, Oct 24, 2022 at 9:48 AM dan via LibreQoS
>> >> <libreqos@lists.bufferbloat.net> wrote:
>> >> >
>> >> > we also have a bunch of 25/5.=C2=A0 It would be nice= to get some more detailed numbers from ookla tests.
>> >>
>> >> +1! We've argued methods with many a provider, and oo= kla and samknows
>> >> are new to this game.
>> >>
>> >> As one example I don't know if they use decimal or bi= nary 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 hi= gher level
>> >> htb categories, total drops will go WAY up,
>> >> and it is best to use the cake drop, ack_drop outputs sta= tistics 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 separatel= y. 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.<= br> >> >>
>> >> Presently (in v1.3.), robert (in grafina?) is summing dro= ps + marks.
>> >> which is a good idea, however perhaps drops, marks and dr= ops+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 r= un cake on egress at
>> >> the cpe, first, doing all this work before it hits the wi= re.
>> >> Are any of you doing that? Openwrt/dd-wrt/firewalla/mikro= tik 7.2?
>> >>
>> >> >We also have a lot of Eero units out there, so watchi= ng for the eero speed test would also be great.
>> >>
>> >> eero 5s have cake (and fq_codel on the wifi), eero 6s hav= e 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 v= ia LibreQoS <libreqos@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 se= rvice 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 bun= ch of 25/5 and similarly asymmetric
>> >> >> connections, in theory it'll help...)
>> >> >>
>> >> >> On Mon, Oct 24, 2022 at 10:31 AM dan via LibreQo= S <l= ibreqos@lists.bufferbloat.net> wrote:
>> >> >>>
>> >> >>> sniff DNS for those speed test lookups and t= rigger a packet capture for x duration?
>> >> >>>
>> >> >>> On Mon, Oct 24, 2022 at 9:27 AM Dave Taht &l= t;dave.taht@gmail.= com> wrote:
>> >> >>>>
>> >> >>>> On Mon, Oct 24, 2022 at 8:20 AM dan <= dandenson@gmail.co= m> wrote:
>> >> >>>> >
>> >> >>>> > Dave, I think that 'bouncing= 9; is more CPU time in the browser.=C2=A0 I don't think it's indica= tive over what's actually happening.
>> >> >>>>
>> >> >>>> A simultaneous packet capture and wiresh= ark plot of the RTTs would
>> >> >>>> also be helpful.
>> >> >>>>
>> >> >>>> >
>> >> >>>> > On Mon, Oct 24, 2022 at 9:09 AM Dav= e Taht via LibreQoS <libreqos@lists.bufferbloat.net> wrote:
>> >> >>>> >>
>> >> >>>> >> On Mon, Oct 24, 2022 at 8:02 AM= Robert Chac=C3=B3n via LibreQoS
>> >> >>>> >> <libreqos@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 - witho= ut Libre we see download bloat of 300ms or so. With Libre, it's gone. O= n 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 c= apture a movie of it...
>> >> >>>> >> >
>> >> >>>> >> > And I like the "monit= or only" mode idea.
>> >> >>>> >> > Perhaps we could create th= e 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 pa= ssive 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 co= uld use eBPF PPing just for this passive monitoring period?
>> >> >>>> >> >
>> >> >>>> >> >
>> >> >>>> >> > On Mon, Oct 24, 2022 at 8:= 02 AM Herbert Wolverson via LibreQoS <libreqos@lists.bufferbloat.net> wr= ote:
>> >> >>>> >> >>
>> >> >>>> >> >> Are you looking for a = shaped result? That'll show "whatever bandwidth
>> >> >>>> >> >> is left on the sector&= quot; without Libre, and around the customer's paid-for
>> >> >>>> >> >> target with Libre (hop= efully!).
>> >> >>>> >> >>
>> >> >>>> >> >> One thing Preseem does= well is that their onboarding process includes
>> >> >>>> >> >> "leave it in moni= toring-only mode" for a week, gathering data before you
>> >> >>>> >> >> pull the switch (altho= ugh most ISPs I've talked to just pull the switch...)
>> >> >>>> >> >> It's quite enlight= ening to see a before/after, even with only FQ_CODEL
>> >> >>>> >> >> as the shaper.
>> >> >>>> >> >>
>> >> >>>> >> >> We could probably do s= omething 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 a= t 8:52 AM Dave Taht via LibreQoS <libreqos@lists.bufferbloat.net> wrote:=
>> >> >>>> >> >>>
>> >> >>>> >> >>> I am curious if an= yone 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=C3=A4ht CEO= , TekLibre, LLC
>> >> >>>> >> >>> __________________= _____________________________
>> >> >>>> >> >>> LibreQoS mailing l= ist
>> >> >>>> >> >>> LibreQoS@lists.bufferbloa= t.net
>> >> >>>> >> >>> https://lists.bufferbloat.net/listinfo/libreqos
>> >> >>>> >> >>
>> >> >>>> >> >> ______________________= _________________________
>> >> >>>> >> >> LibreQoS mailing list<= br> >> >> >>>> >> >> LibreQoS@lists.bufferbloat.ne= t
>> >> >>>> >> >> = https://lists.bufferbloat.net/listinfo/libreqos
>> >> >>>> >> >
>> >> >>>> >> >
>> >> >>>> >> >
>> >> >>>> >> > --
>> >> >>>> >> > Robert Chac=C3=B3n
>> >> >>>> >> > CEO | JackRabbit Wireless = LLC
>> >> >>>> >> > __________________________= _____________________
>> >> >>>> >> > LibreQoS mailing list
>> >> >>>> >> > LibreQoS@lists.bufferbloat.net
>> >> >>>> >> > http= s://lists.bufferbloat.net/listinfo/libreqos
>> >> >>>> >>
>> >> >>>> >>
>> >> >>>> >>
>> >> >>>> >> --
>> >> >>>> >> This song goes out to all the f= olk that thought Stadia would work:
>> >> >>>> >> https://www.linkedin.com/posts/dtaht_the-= mushroom-song-activity-6981366665607352320-FXtz
>> >> >>>> >> Dave T=C3=A4ht CEO, TekLibre, L= LC
>> >> >>>> >> _______________________________= ________________
>> >> >>>> >> LibreQoS mailing list
>> >> >>>> >> LibreQoS@lists.bufferbloat.net
>> >> >>>> >> https://l= ists.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-so= ng-activity-6981366665607352320-FXtz
>> >> >>>> Dave T=C3=A4ht CEO, TekLibre, LLC
>> >> >>>
>> >> >>> ____________________________________________= ___
>> >> >>> LibreQoS mailing list
>> >> >>> LibreQoS@lists.bufferbloat.net
>> >> >>> https://lists.bufferbl= oat.net/listinfo/libreqos
>> >> >>
>> >> >> _______________________________________________<= br> >> >> >> LibreQoS mailing list
>> >> >> LibreQoS@lists.bufferbloat.net
>> >> >> https://lists.bufferbloat.= net/listinfo/libreqos
>> >> >
>> >> > _______________________________________________
>> >> > LibreQoS mailing list
>> >> > LibreQoS@lists.bufferbloat.net
>> >> > https://lists.bufferbloat.net/= listinfo/libreqos
>> >>
>> >>
>> >>
>> >> --
>> >> This song goes out to all the folk that thought Stadia wo= uld work:
>> >> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-69813= 66665607352320-FXtz
>> >> Dave T=C3=A4ht CEO, TekLibre, LLC
>> >> _______________________________________________
>> >> LibreQoS mailing list
>> >> LibreQoS@lists.bufferbloat.net
>> >> https://lists.bufferbloat.net/listi= nfo/libreqos
>> >
>> >
>> >
>> > --
>> > Robert Chac=C3=B3n
>> > CEO | JackRabbit Wireless LLC
>>
>>
>>
>> --
>> This song goes out to all the folk that thought Stadia would work:=
>> htt= ps://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-69813666656073= 52320-FXtz
>> Dave T=C3=A4ht CEO, TekLibre, LLC



--
This song goes out to all the folk that thought Stadia would work:
https://www.= linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXt= z
Dave T=C3=A4ht CEO, TekLibre, LLC
_______________________________________________
LibreQoS mailing list
LibreQo= S@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/libreqos
--000000000000bc109105ebcba739--