[LibreQoS] Rain Fade (was Ack-filtering)

[Herbert Wolverson]

Rain fade (short version, at home now). 5.x and 2.4 barely change. 3.6, we
see a tiny fade. If there is any foliage in the way, it gets a lot worse.

We gave up on 24ghz, it faded if I looked too hard at it.

Ubiquiti's AF60-LR seems to do better than it should, for a 60ghz - partly
by running up in the 70ghz channel. We have a 2 mile link that kept
carrying a gig while the flooding started. (I kinda suspect it's playing
fast and loose with the rules, honestly). Other 60ghz units fade horribly.

On Mon, Oct 24, 2022, 6:05 PM Dave Taht <dave.taht at gmail.com> wrote:

> On Mon, Oct 24, 2022 at 3:58 PM Herbert Wolverson <herberticus at 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 at gmail.com> wrote:
> >>
> >> On Mon, Oct 24, 2022 at 2:19 PM Herbert Wolverson via LibreQoS
> >> <libreqos at 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/libreqos/attachments/20221024/a10e01e1/attachment.html>