From: Dave Taht <dave.taht@gmail.com>
To: Herbert Wolverson <herberticus@gmail.com>
Cc: libreqos@lists.bufferbloat.net
Subject: Re: [LibreQoS] Ack-filtering
Date: Mon, 24 Oct 2022 14:57:13 -0700 [thread overview]
Message-ID: <CAA93jw7xrikwQnPHGPAcL2Y3WHeuKZkuV-h-OL-nGBmxF2XJJw@mail.gmail.com> (raw)
In-Reply-To: <CA+erpM5A9FM_rkubOiOCT_d0UAUar_Sw=jwOVb3RDTWcztvXRw@mail.gmail.com>
On Mon, Oct 24, 2022 at 2:19 PM Herbert Wolverson via LibreQoS
<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 quick'n'dirty results of testing "ack-filter":
>
> We've been having a Bad Network Day (TM), with sudden flooding making us 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 digesting 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. 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 towards 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 "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-6981366665607352320-FXtz
Dave Täht CEO, TekLibre, LLC
next prev parent reply other threads:[~2022-10-24 21:57 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-24 21:19 Herbert Wolverson
2022-10-24 21:48 ` Dave Taht
2022-10-24 21:57 ` Dave Taht [this message]
2022-10-24 22:58 ` Herbert Wolverson
2022-10-24 23:05 ` [LibreQoS] Rain Fade (was Ack-filtering) Dave Taht
2022-10-24 23:25 ` dan
2022-10-25 0:43 ` Mark Steckel
2022-10-25 13:25 ` dan
2022-10-25 13:43 ` Herbert Wolverson
2022-10-25 13:58 ` dan
2022-10-25 16:56 ` Dave Taht
2022-10-26 2:22 ` dan
2022-10-26 2:28 ` [LibreQoS] 10G radios Was: " Mark Steckel
2022-10-26 4:09 ` dan
2022-10-26 12:57 ` Mark Steckel
2022-10-26 13:02 ` Herbert Wolverson
2022-10-26 15:02 ` dan
2022-10-26 3:26 ` [LibreQoS] " Dave Taht
2022-10-26 13:27 ` Herbert Wolverson
2022-10-26 14:52 ` dan
2022-10-24 23:25 ` Herbert Wolverson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/libreqos.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA93jw7xrikwQnPHGPAcL2Y3WHeuKZkuV-h-OL-nGBmxF2XJJw@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=herberticus@gmail.com \
--cc=libreqos@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox