Joined: 08 May 2018 Posts: 14246 Location: Texas, USA
Posted: Wed Sep 09, 2020 13:37 Post subject:
The secondary vehicle is "smart" enough. Drive by wire, save and except for steering, brakes, and drivetrain. Everything else is electronic sensors. My Tacoma is one of the last model years with an actual throttle cable. I'd rather risk it sticking wide open or breaking than having SkyNet decide my fate
Joined: 21 Jan 2017 Posts: 1783 Location: Illinois Moderator
Posted: Wed Sep 16, 2020 3:43 Post subject:
FOUND THE CULPRIT....
802.11r
had it enabled on both radios...
My best guess at the whole mess...
despite the wifi being off on the appliance, when it is first turned on the default is that it starts broadcasting as an AP and then turns off in 3-10 seconds... That's just long enough to disrupt the wifi environment and cause devices to want to jump ship...
turning off 802.11r made the issue go away.
I'll keep my eye's peeled on the status window and will reply back if this gremlin comes back, but I don't think it will. _________________ FORUM RULES
Joined: 21 Jan 2017 Posts: 1783 Location: Illinois Moderator
Posted: Thu Oct 22, 2020 17:19 Post subject: Beacon Interval was the solution!
OK, I've been upgrading the nightly builds so far and as of the last month or so I haven't noticed any issues...
So here is the solution that was implemented:
I changed both radio's beacon interval to something that was more realistic. 100 is a very very short window for a beacon interval. Stealing from the "idealogy" of bluetooth beacons used for position detection, a 100 beacon will eat through battery like none other for bluetooth position sensors. The same science/theory applies to wifi. Having a super low beacon interval will cause your wifi clients to always get pinged by the router thus reducing battery life of your phone/tablet/laptop.
Applies to Bluetooth:
But here is how it looks to the router when you physically move and have the various beacon intervals:
So you can see that having a super short beacon interval is not really useful and setting it between 300 and 600 is a happy "split the difference" solution. This is what ultimately led me to use the values I am using- with great success to boot!
I ended up settling on:
Code:
5g: 300 & DTIM=1
2.4g: 400 & DTIM=1
Edited the above to remove the prime numbers suggestion. Too many IoT devices want increments of 50 to be used for beacon interval...using a prime number will yield issues for some clients, so stick to the above.
Changing from DTIM 2 to 1 seems to have made a difference, too, because otherwise the beacon is nearly 1 second long
(dtim=2- so every other beacon = double the time) which makes for a bad experience for moving/mobile devices on wifi.
This seems to have stopped the washer and dryer from blasting out whatever pulse they broadcast and killing the router's wifi for milliseconds causing clients to jump the 5ghz ship for 2.4ghz.... It's been amazingly stable now with the beacon intervals set at the above.
I will get around to making this official in the best settings sticky and wiki's for bcm and qca wifi... but until then I will leave this nugget of info for the dedicated readers.
My settings on two E2100L units WDS-AP & WDS-Sta that only talk to each other using oldass r27506 (2015).
Signal shoots thru powerlines and across state hywy.
Only thing I found that won't drop wireless.
Joined: 18 Mar 2014 Posts: 12917 Location: Netherlands
Posted: Fri Oct 23, 2020 16:16 Post subject:
Strange observation, I used your settings and everything worked well except one IOT device on my VAP, this would not function, the connection status showed Legacy2.5
I lowered the Beacon interval to 199 and then it started to function again, showing connection HT20
Joined: 21 Jan 2017 Posts: 1783 Location: Illinois Moderator
Posted: Fri Oct 23, 2020 17:04 Post subject:
egc wrote:
Strange observation, I used your settings and everything worked well except one IOT device on my VAP, this would not function, the connection status showed Legacy2.5
I lowered the Beacon interval to 199 and then it started to function again, showing connection HT20
(router R7800 running build 44467)
IoT devices are a total crapshoot with their low cost chipsets and what drivers are hard baked in... We'll have to keep an eye out and see if we can come to a consensus, but I think it may end up that we will need to be at multiples of 100...
See what happens with 300 for me please. I'm curious is the prime number may be the issue since it's a funky time unit value and might be actually rounding to something else...I haven't dug into the cli to see what is actually happening in a while... _________________ FORUM RULES
Joined: 21 Jan 2017 Posts: 1783 Location: Illinois Moderator
Posted: Fri Oct 23, 2020 17:47 Post subject:
egc wrote:
300 works, dtim still on 1
so that IoT device has shit code that cannot handle prime number time units... I wonder how much you can deviate from increments of 100 before it turns to shit...
I know a long list and don't expect, or ask, to test all values in the list...but I bet it's within 5%-10% or so...not sure what kind of error/buffer is built into the code... maybe a worthwhile question to BS to see if there is some tolerance in the 802.11 standard for beacon TU...there must be one.... _________________ FORUM RULES
Edited the above to remove the prime numbers suggestion. Too many IoT devices want increments of 50 to be used for beacon interval...using a prime number will yield issues for some clients, so stick to the above.
I will get around to making this official in the best settings sticky and wiki's for bcm and qca wifi... but until then I will leave this nugget of info for the dedicated readers.
The wiki still has info about using prime #'s. Was it determined that this should remain in place or has it just not been updated yet with this newer information? _________________ --Netgear R7800--
DD-WRT v3.0-r49492 std (07/14/22)