From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 C51DC3B29E for ; Mon, 24 Oct 2022 18:58:31 -0400 (EDT) Received: by mail-pf1-x42e.google.com with SMTP id g16so4787022pfr.12 for ; Mon, 24 Oct 2022 15:58:31 -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=JCfTWKo/KiXkW/Uzd/s61eOS0VJjwEZwhej/06b+wmI=; b=iPHXwx2Xchlitrf2jirA9JqOee7xZxGTxcGyWXidtHyjEIAsJJvh1G/aTcYWe6GEcn xlRIgW0wBHpYucygH1yJgWhm7Bj7Qkn3w8tXT/pFwuXX/O1Vk7DEsSAHuxqG77zoZd3q eB2Q1EQ1aDQCOg4oPGsn6BKBngL+Vntg8w2Cu1DXIrX8qR4Hk//05pocatMzsTt3JvPr IM4QCJvxI1lQ+6zbjxJjHV5z+AB03rbUYNlhrz3Dxbm0g29qIqmfwxG0HKGedLu8ELGy XmJiWiO0eTaHjEgW1E4gg3UPdcYMkEaqjrphE20soFtbQyM91wpH8tih+Jwj9fatyqlz 3vsQ== 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=JCfTWKo/KiXkW/Uzd/s61eOS0VJjwEZwhej/06b+wmI=; b=HugRHG95jweddX2YhV1dGL5gH+zwiUROSbI6wEm+Ao0ehsUJmO1W837WxpY1LdyKLV 9oltad02tyXK3vC/lhKzkrxiz/DEbwqQWHAcYHKtdmLo2Mf0aJ4F+s2vL9hB2yo3afnt 8OiYrpAJX5b9MKRWj/iLV/U0Is4AIfL5IE6BUMxHYh73N+16D4nPQBW4wQvwhOmW2USu XWFoE8tutexO3ZC5QH+5g9nJgO6fGpNA3Pg6rmv9CgkozJm7+YzRIh+uikk8ZL20sB1k +S/ApPo4L9msxNqfwC7cEdTWxu6MpFvwhm6HxxiJtovsYMMAAB11T0KVVV3w8Npd/7ea 7fYg== X-Gm-Message-State: ACrzQf1hdhEGCU4cejK24Yor9Yc1L+5t80qRDTwqu1eOZwIY+G03RPuL PkIzLIp2oE6Euvfa/32Lab1/5v+Fg1k0H1tliuUOwrrt X-Google-Smtp-Source: AMsMyM4LUULCFd/y1GbNFF6XG+MxsoItEJZVcSvyN/Al00UYjyz0n/YvGBk/y+ln65X3YtSFIeNnXDYLwSgk4oOaQmU= X-Received: by 2002:a65:6e0e:0:b0:434:59e0:27d3 with SMTP id bd14-20020a656e0e000000b0043459e027d3mr29176751pgb.185.1666652310769; Mon, 24 Oct 2022 15:58:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Herbert Wolverson Date: Mon, 24 Oct 2022 17:58:18 -0500 Message-ID: To: Dave Taht Cc: libreqos@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="000000000000f2961805ebcfbaba" Subject: Re: [LibreQoS] Ack-filtering 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 22:58:31 -0000 --000000000000f2961805ebcfbaba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hit the wrong reply button, that happens a lot when I try to type on my phone. I'm going to test tracking many more flows early in the morning. It should slightly increase ram usage, and have no ill effects. "Should" doesn't always work out, hence testing! I meant "flooding" in the "oh crap, site underwater" sense. We'd need a boat to get to one tower right now! It doesn't currently have power, which I suspect is related. Turned ack filter off, after some customers reported issues (others were really happy). The unhappy campers were all on Cambium devices, with good signal and modulations. Maybe Cambium is doing some "magic"? We'll try a unidirectional test tomorrow. On Mon, Oct 24, 2022, 4:57 PM Dave Taht wrote: > On Mon, Oct 24, 2022 at 2:19 PM Herbert Wolverson via LibreQoS > wrote: > > > > Highly un-scientific (we need to let it run for a bit and do a proper > before-after comparison that includes a decent timeframe), but I like the > quick'n'dirty results of testing "ack-filter": > > > > We've been having a Bad Network Day (TM), with sudden flooding making u= s > use some pretty constrained > > I've been looking at various ddos mitigation schemes of late. Are you > using any? > > >- so our latencies were really suffering in one region. That region just > happens to be the worst part of our network (we haven't finished digestin= g > an acquisition; there's even Bullet M2 omnis up there!). Lots of relative= ly > low-speed plans, all with big variance (10/3, 25/5, I found a 5/1 that > someone forgot to upgrade!). They seem to have benefitted greatly. The > parts of the network that were doing great - are still doing great, with > very little change. > > I made my previous comments in looking at the swing downwards being so > large, possibly not being a positive direction (my ever suspicious gut > was reacting, but I wasn't qualifying the numbers - been a long day > here too) > > I also forgot to mention that ack-filtering uses up less txops on > older versions of wifi. Very useful. I'd meant > to put it into my mt76 stuff ages ago but got overwhelmed by bugs. > > > Just a quick'n'dirty test. I'll try and put something more useful > together tomorrow, when it's had a chance to see how peak time hits it. > > :crossed fingers: > > > > > (Also, this digging revealed an issue with pping-cpumap in production. > It wasn't tracking enough flows, so the reporting is heavily biased towar= ds > the top-consumers - who are likely to be monitored before the buffer fill= s > up and it stops counting until stats are read. So I added a "maximums.h" > file to make it easy to set user limits, and made flow-count derive from > that.) > > I think polling it more frequently would be closer to the typical > durations of flows. Most flows last for under 3 seconds. > > What would be the harm in vastly expanding the number of flows it tracks? > > /me hides > > > _______________________________________________ > > 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 > --000000000000f2961805ebcfbaba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hit the wrong reply button, that happens a lot when I try= to type on my phone.

I'm = going to test tracking many more flows early in the morning. It should slig= htly increase ram usage, and have no ill effects. "Should" doesn&= #39;t always work out, hence testing!

I meant "flooding" in the "oh crap, site under= water" sense. We'd need a boat to get to one tower right now! It d= oesn't currently have power, which I suspect is related.

Turned ack filter off, after some cus= tomers reported issues (others were really happy). The unhappy campers were= all on Cambium devices, with good signal and modulations. Maybe Cambium is= doing some "magic"? We'll try a unidirectional test tomorrow= .

On Mon, Oct 24, 2022, 4:57 PM Dave Taht <dave.taht@gmail.com> wrote:
On Mon, Oct 24, 2022 at 2:19 PM Herbert Wolverson via LibreQ= oS
<libreqos@lists.bufferbloat.net> wrote:
>
> Highly un-scientific (we need to let it run for a bit and do a proper = before-after comparison that includes a decent timeframe), but I like the q= uick'n'dirty results of testing "ack-filter":
>
> We've been having a Bad Network Day (TM), with sudden flooding mak= ing us use some pretty constrained

I've been looking at various ddos mitigation schemes of late. Are you u= sing any?

>- so our latencies were really suffering in one region. That region jus= t happens to be the worst part of our network (we haven't finished dige= sting an acquisition; there's even Bullet M2 omnis up there!). Lots of = relatively low-speed plans, all with big variance (10/3, 25/5, I found a 5/= 1 that someone forgot to upgrade!). They seem to have benefitted greatly. T= he parts of the network that were doing great - are still doing great, with= very little change.

I made my previous comments in looking at the swing downwards being so
large, possibly not being a positive direction (my ever suspicious gut
was reacting, but I wasn't qualifying the numbers - been a long day
here too)

I also forgot to mention that ack-filtering uses up less txops on
older versions of wifi. Very useful. I'd meant
to put it into my mt76 stuff ages ago but got overwhelmed by bugs.

> Just a quick'n'dirty test. I'll try and put something more= useful together tomorrow, when it's had a chance to see how peak time = hits it.

:crossed fingers:

>
> (Also, this digging revealed an issue with pping-cpumap in production.= It wasn't tracking enough flows, so the reporting is heavily biased to= wards the top-consumers - who are likely to be monitored before the buffer = fills up and it stops counting until stats are read. So I added a "max= imums.h" file to make it easy to set user limits, and made flow-count = derive from that.)

I think polling it more frequently would be closer to the typical
durations of flows. Most flows last for under 3 seconds.

What would be the harm in vastly expanding the number of flows it tracks?
/me hides

> _______________________________________________
> LibreQoS mailing list
> LibreQoS@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinf= o/libreqos



--
This song goes out to all the folk that thought Stadia would work:
h= ttps://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698136666560= 7352320-FXtz
Dave T=C3=A4ht CEO, TekLibre, LLC
--000000000000f2961805ebcfbaba--