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: [LibreQoS] Rain Fade (was  Ack-filtering)
Date: Mon, 24 Oct 2022 16:05:34 -0700	[thread overview]
Message-ID: <CAA93jw5EsqPmmsQOdMuagD+fN+hddAgwNVrabPgHwents-SzGQ@mail.gmail.com> (raw)
In-Reply-To: <CA+erpM7MWRaSxjANNQpU=KvVKdygDxUcxsCK=U-rgPGtEwQJ7A@mail.gmail.com>

On Mon, Oct 24, 2022 at 3:58 PM Herbert Wolverson <herberticus@gmail.com> wrote:
>
> 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.

re: flooding, yea, forgot about that kind. :) I hate to harp on it
more than once a week, but we designed fq_codel first and foremost to
cope with rain fade on the backhaul. Now that people just use it to
enforce plans :( gathering statistics as to radio behaviors when it
rains, and/or clearly identifying weather, when looking at historical
data seems apt.

How bad are y'all's gear doing with rain fade on various techs and
bands? in 08, in nica, I'd go from a working 70 db 10 mile shot to
nothin at 5ghz when it rained, and I just laughed at the people trying
to deploy 60ghz - but times change. I see a vendor trying to ship 60
with *really good antennas* into the office market...

big question to ask when so busy, please ignore me.

>
> 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.

Maybe an exceptions db for stuff that is too smart or weird. TCP
"accellerator"s are everywhere.

>
> 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 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



-- 
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

  reply	other threads:[~2022-10-24 23:05 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-24 21:19 [LibreQoS] Ack-filtering Herbert Wolverson
2022-10-24 21:48 ` Dave Taht
2022-10-24 21:57 ` Dave Taht
2022-10-24 22:58   ` Herbert Wolverson
2022-10-24 23:05     ` Dave Taht [this message]
2022-10-24 23:25       ` [LibreQoS] Rain Fade (was Ack-filtering) 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=CAA93jw5EsqPmmsQOdMuagD+fN+hddAgwNVrabPgHwents-SzGQ@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