From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C137D3CB39 for ; Sun, 25 Mar 2018 16:16:13 -0400 (EDT) Received: by mail-wm0-x22e.google.com with SMTP id i75so11777158wmf.0 for ; Sun, 25 Mar 2018 13:16:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cKPA5P7fk3nGRyKiZXUICsTif3x1krIgBSZM8zxRASw=; b=IpzfvDaWOjxjX9wIKPgmawibqZc19dJLU77KAfaLpNH38lkiS2tQQVl+52W1Y2di1C nKWldBrftsxbWJCW442u4NZn7zI1pO8uKKCb2gvSuKA1rRx9kdbh0B9VuSyD6myvhKtA PUbdXSHNC6huppZlWgTEwawBjq4UPqWVhaV74= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cKPA5P7fk3nGRyKiZXUICsTif3x1krIgBSZM8zxRASw=; b=kFPBNwn2LjDh30iegN1l7pCSIEKxuQBIrp+PitGD+B6y5/BGhsvwMbpeOcMo9taScO KeTi2qV+KjJTJIWB6fNk8iACLROVmr1YLljtfhKhKosVyJW1Njg0j7IWP/0Ek4aD64Jb +mnL5wgOj0rqPL6brUh3OSy9V7b9qfrUwR6mvXKcbt9AVbO1O4ozSOSfw6GhjjRXkLeY rtTNI6x7hUDFtoQHBDnDh/dNjyX4JAXruUKt2WNF4h/xnYH8pV2ytAPpHPnT+m1VEndR 3Yz3RtiHhqPUozdWNyg0QtEJGgR+AojzHYytWlD4HF52k5DgES9VrOwn8D0FxeEOzj3l DMGw== X-Gm-Message-State: AElRT7FF5hE4T5Blv0ks0JqRzdFxVX3FBgqoAcwyvQQuPzze+c/drYDM Utm7pmj5QVa7XrCDTvCNe0LPgb5lzyk9bZsp3X0lvw== X-Google-Smtp-Source: AG47ELs44Krj8Y82zad5VUOW4fw5P/YFY3EXH2/70J4kxk5FfaMf94/hEkmHcrsFA67OQXU0izs/E9Z6NtVVY/Wtm2Y= X-Received: by 10.80.186.14 with SMTP id g14mr37796764edc.302.1522008972682; Sun, 25 Mar 2018 13:16:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.159.195 with HTTP; Sun, 25 Mar 2018 13:16:12 -0700 (PDT) In-Reply-To: <1521924762.93563937@mobile.rackspace.com> References: <1521924762.93563937@mobile.rackspace.com> From: Bob McMahon Date: Sun, 25 Mar 2018 13:16:12 -0700 Message-ID: To: "dpreed@deepplum.com" Cc: Dave Taht , Rich Brown , Make-Wifi-fast Content-Type: multipart/alternative; boundary="f403045c38402992660568425478" Subject: Re: [Make-wifi-fast] Latency spikes every few minutes? X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 20:16:14 -0000 --f403045c38402992660568425478 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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@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 wit= h > 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, po= or > 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" > Sent: Fri, Mar 23, 2018 at 5:15 pm > To: "Rich Brown" > Cc: "Rich Brown" , make-wifi-fast@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 al= l > 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@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/make-wifi-fast > > > > -- > > Dave T=C3=83=C2=A4ht > CEO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-669-226-2619 > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@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@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast > --f403045c38402992660568425478 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agreed w/David.

Scan times are typically based upon= the beacon rate and the number of channels to scan.=C2=A0 W/o a "simp= le secondary receiver for scan support," things like roaming actually = cost more (in latency) to decide to roam (or not) and to where vs. the actu= al switching latency.

The channel map per some smart "system&qu= ot; seems to me maybe a good idea too.=C2=A0 =C2=A0Possibly even a machine = learning backend that calculate and pass the maps to the APs which in turn = passed them to STAs.=C2=A0 The feature vectors for map generation could be = things like network traffic metrics and phy channel estimates.=C2=A0 Again,= just a wild idea.

Bob

On Sat, Mar 24, 2018 at 1:52 PM, dpreed@deepplum.com <dpreed@deepplum.com> wrote:
My understanding, which may be = wrong, is that a channel scan requires listening for either a packet or a b= eacon on each channel. Beacons being the longest you have to wait. But addi= ng up across all the 5 GHz channels + 2.4 GHz channels, assuming most are u= nused, you get real long delays!

A better idea would be listening for beacons with a simple secondary receiv= er. That receiver could be a variable bandwidth front end, so it could list= en 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 sig= nals than the current one, because you could just open the channel filter b= andwidth (getting worse SNR) and use SDR to sample for louder signals, if a= ny.

Conceptually, what you probably want is good hints about what fallback chan= nel you might switch to. Channel scanning one at a time is a poor, poor alg= orithm for that.

And even for fixed stations, propagation varies -- turn on a fan in the roo= m causing time varying multipath distortion, or open a metal filing cabinet= drawer. So a fallback is useful to have for quick association switching. H= owever, the ideal thing at that point is to be associated simultaneously wi= th multiple APs or mesh peers, and maybe even have DHCP leases with fallbac= k nets.

-----Original Message-----
From: "Dave Taht" <dave= .taht@gmail.com>
Sent: Fri, Mar 23, 2018 at 5:15 pm
To: "Rich Brown" <r= ichb.hanover@gmail.com>
Cc: "Rich Brown" <r= ichb.hanover@gmail.com>, make-wifi-fast@lists.bufferbloat.net
Subject: Re: [Make-wifi-fast] Latency spikes every few minutes?

On Fri, Mar 23, 2018 at 2:12 PM, Rich Brown=C2=A0 wrote:
> Hi folks,
>
> My Google-fu is weak today. I know that someone described the reason t= hat some Wifi sees big latency spikes every few minutes. I remember it bein= g 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_cha= nnel_scans/
>
> Rich
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast= @lists.bufferbloat.net
> https://lists.bufferbloat.net/listin= fo/make-wifi-fast



--

Dave T=C3=83=C2=A4ht
CEO, TekLibre, LLC
ht= tp://www.teklibre.com
Tel: 1-669-226-2619
_______________________________________________
Make-wifi-fast mailing list
Make-wifi-fast@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/mak= e-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@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/mak= e-wifi-fast

--f403045c38402992660568425478--