From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com [IPv6:2607:f8b0:4864:20::1133]) (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 205C63B29E for ; Mon, 24 Oct 2022 14:03:36 -0400 (EDT) Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-3691e040abaso92426397b3.9 for ; Mon, 24 Oct 2022 11:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ve8dIM4kq+pE3lgJwCgbQ+5CWYQvSim7saGbVl7yuEE=; b=Zl4ZTBHMp1EExBhHJyQr/D7aJscw/wFYfFOSA1nryQ5MHY1nM1dhikvcnNWh9Xt0nF cfGywGRJZ8ivvKa/t612UF7laMJQs9LRXG5dTu+Z8iEe/XZDCK14SbR7Vj/hS1zxesz5 w69Qnh8fCW97fdaW+qVJ3/trjMbLUnkGFNDPxyAME2SQ+y9QnprjuQTgfNvV2I1Ikmud +TqM1V5uakQerCS7/1mRAgKYCGU2LYeI939rvdvxK4Ky624vzWZ6LJ6G4hevvWAEFQ+c SQaBo+D2SeQ3OczfKjNu0o5ysKhzRvD0HRw2FmWQJ3CH/61ya0m5ZKbc9VgBCaRbPCXr 17FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to: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=ve8dIM4kq+pE3lgJwCgbQ+5CWYQvSim7saGbVl7yuEE=; b=3PRniv+4axwqQjPx5TRLlL8NHM62/jOe9YniWV2InkX4XL5A52Sp92Twq2jMjpH4F0 rjZIG5gXDHOuXUnKKM9daHc3+LFboTi/lrW5KRs1HbE2twoGnWORdBnkv6cgC6A9Y4ad 60S2iV6kWXnkrFW9iX/pwgtLxEyGrdBWEuYJHu1r9uzGtSnuMhxAzVQMMRJr7rnNHY+n +B5Cklq+Gj43BMD77maCNUyUO7gvIK4VK2uzG4VWETOGOrxXmEhiZOdHqA5d08mC9rEO W1bRf3FdrGoWxDmlGBbn5Un8gA6D8IrMAIygLiXguloDwST5FLsdnrHEq0qx8TUYOagD 0GbA== X-Gm-Message-State: ACrzQf1qbeyO1heSh+Z/MLLRAPNqpMvdBbh/10ipJFXCfrC1ppqVdbeR kQGdkQ9suY34bqn4ZeN1LJUC/T42aLYMBuh5Keg= X-Google-Smtp-Source: AMsMyM7OM9YXOPblPITnbHG+OTuCA15jwyDpOv6pCUSngxCIx1uRWOD5dcRc5K4DesZp9li5zYcegnI5m+geHkqZpwk= X-Received: by 2002:a81:484a:0:b0:36b:7d6c:d85 with SMTP id v71-20020a81484a000000b0036b7d6c0d85mr9987265ywa.8.1666634615133; Mon, 24 Oct 2022 11:03:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: dan Date: Mon, 24 Oct 2022 12:03:24 -0600 Message-ID: To: Dave Taht Cc: =?UTF-8?Q?Robert_Chac=C3=B3n?= , libreqos@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="000000000000349c7305ebcb9c57" 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:03:36 -0000 --000000000000349c7305ebcb9c57 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 pu= sh > 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 pla= n > 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 + mark= s. > >> > 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 - 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. > >> > >> 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 samkno= ws > >> >> 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 somewh= at > >> >> buggy fq_codel offload: > >> >> > >> >> > https://www.reddit.com/r/eero/comments/u7xm83/gen_2_sqm_vs_gen_3_sqm_stic= k_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 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@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 Libr= eQoS > >> >> >>>> >> 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 thi= s > 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, 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@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-698136666= 5607352320-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 woul= d > work: > >> >> >>>> >> > https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698136666= 5607352320-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-698136666= 5607352320-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-698136666= 5607352320-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-698136666= 5607352320-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-698136666= 5607352320-FXtz > Dave T=C3=A4ht CEO, TekLibre, LLC > --000000000000349c7305ebcb9c57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We're pretty far past that hardware.=C2=A0 Minimum pla= ns at most sites are now 100x20 and we're moving rapidly to 200x200-1Gx= 1G plans.=C2=A0 The implication being that we need 4x4 AX wifi radios and t= hat's real tough in an openwrt compatible hardware right now, not a ton= of options.=C2=A0

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

On Mon, Oct 24, 2022 at 11:57 AM Dave Taht &l= t;dave.taht@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
--000000000000349c7305ebcb9c57--