Many ISPs need the kinds of quality shaping cake can do
 help / color / mirror / Atom feed
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

  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