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