[Make-wifi-fast] Latency spikes every few minutes?
Bob McMahon
bob.mcmahon at broadcom.com
Sun Mar 25 16:16:12 EDT 2018
Agreed w/David.
Scan times are typically based upon the beacon rate and the number of
channels to scan. W/o a "simple secondary receiver for scan support,"
things like roaming actually cost more (in latency) to decide to roam (or
not) and to where vs. the actual switching latency.
The channel map per some smart "system" seems to me maybe a good idea too.
Possibly even a machine learning backend that calculate and pass the maps
to the APs which in turn passed them to STAs. The feature vectors for map
generation could be things like network traffic metrics and phy channel
estimates. Again, just a wild idea.
Bob
On Sat, Mar 24, 2018 at 1:52 PM, dpreed at deepplum.com <dpreed at deepplum.com>
wrote:
> My understanding, which may be wrong, is that a channel scan requires
> listening for either a packet or a beacon on each channel. Beacons being
> the longest you have to wait. But adding up across all the 5 GHz channels +
> 2.4 GHz channels, assuming most are unused, you get real long delays!
>
> A better idea would be listening for beacons with a simple secondary
> receiver. That receiver could be a variable bandwidth front end, so it
> could listen on adjacent channel groups at the same time, in parallel with
> the normal stuff.
>
> It would be even easier if you were only interested in newer and louder
> signals than the current one, because you could just open the channel
> filter bandwidth (getting worse SNR) and use SDR to sample for louder
> signals, if any.
>
> Conceptually, what you probably want is good hints about what fallback
> channel you might switch to. Channel scanning one at a time is a poor, poor
> algorithm for that.
>
> And even for fixed stations, propagation varies -- turn on a fan in the
> room causing time varying multipath distortion, or open a metal filing
> cabinet drawer. So a fallback is useful to have for quick association
> switching. However, the ideal thing at that point is to be associated
> simultaneously with multiple APs or mesh peers, and maybe even have DHCP
> leases with fallback nets.
>
> -----Original Message-----
> From: "Dave Taht" <dave.taht at gmail.com>
> Sent: Fri, Mar 23, 2018 at 5:15 pm
> To: "Rich Brown" <richb.hanover at gmail.com>
> Cc: "Rich Brown" <richb.hanover at gmail.com>, make-wifi-fast at lists.
> bufferbloat.net
> Subject: Re: [Make-wifi-fast] Latency spikes every few minutes?
>
> On Fri, Mar 23, 2018 at 2:12 PM, Rich Brown wrote:
> > Hi folks,
> >
> > My Google-fu is weak today. I know that someone described the reason
> that some Wifi sees big latency spikes every few minutes. I remember it
> being related to an AP scanning something, for some reason, but that's all
> I remember. Could someone refresh my brain? Thanks.
>
> http://blog.cerowrt.org/post/disabling_channel_scans/
> >
> > Rich
> > _______________________________________________
> > Make-wifi-fast mailing list
> > Make-wifi-fast at lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
>
>
> --
>
> Dave Täht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
> --
> Reed Online Ltd is a company registered in England and Wales. Company
> Registration Number: 6317279.
> Registered Office: Academy Court, 94 Chancery Lane, London WC2A 1DT.
>
>
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20180325/9588edfd/attachment.html>
More information about the Make-wifi-fast
mailing list