Re: issues with scanning in mac80211

Re: issues with scanning in mac80211

[Luis R. Rodriguez]

Massaging this message a bit and putting it on the public
mailing list.

On Thu, Aug 26, 2010 at 01:14:36PM -0700, Amod Bodas wrote:
> Thanks Jouni. Even my observations are same i.e I see 1 sec or
> so scan before returning to home channel. Given background scan
> issue looks to be mac80211 related.
>
> Who is lead scan module expert in the community?

Well Helmut worked on it:

Author: Helmut Schaa <Helmut.Schaa@gmx.de>
Date:   Wed Feb 24 14:19:21 2010 +0100

    mac80211: Improve software scan timing
    
    The current software scan implemenation in mac80211 returns to the operating
    channel after each scanned channel. However, in some situations (e.g. no
    traffic) it would be nicer to scan a few channels in a row to speed up
    the scan itself.
    
    Hence, after scanning a channel, check if we have queued up any tx frames and
    return to the operating channel in that case.
    
    Unfortunately we don't know if the AP has buffered any frames for us. Hence,
    scan only as many channels in a row as the pm_qos latency and the negotiated
    listen interval allows us to.
    
    Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

but AFAICT the issues documented below were likely not considered into the
architecture and its the first time I see them pointed out, unless I missed
something. The above commit log shows only the pm_qos latency was taken
into consideration, which I suppose can be modified for now as a hack
to deal with these issues.

Jouni's observations below.

> -----Original Message-----
> From: Jouni Malinen 
> Sent: Thursday, August 26, 2010 12:22 PM
> To: Amod Bodas
> Cc: Luis Rodriguez
> Subject: Re: issues with scanning in mac80211
> 
> I do not know what is in compat-wireless, but at least the current
> wireless-testing.git background scanning algorithm in mac80211 looks
> pretty horrible from the view point of receiving broadcast frames from
> the current AP. I'm actually getting much worse results..
> My tests show 1020 ms away from operating channel vs. Sam's 175 ms.
> 
> mac80211 does not seem to even try to receive PS buffered
> broadcast/multicast frames. It is only limiting the off-channel scan
> operation based on listen interval (which is 10 with ath9k) which allows
> it to miss ten beacon intervals in row from the current AP even if the
> DTIM period is one.. In addition, the time when it leaves the operating
> channel is not synchronized with the beacons at all. Both of these
> should really be fixed in mac80211 in a way that at least provides an
> optional configuration parameter to try to receive all broadcast frames.
> 
> As far as unicast issues are concerned, I'm not aware of issues in this
> area and would need to see a wireless capture log showing a case where
> mac80211 (or ath9k for that matter) does something wrong. The current
> code seems to return to the operating channel every beacon_int *
> listen_int and as such, is likely to allow the AP to keep unicast frames
> in PS buffer (assuming there is not much traffic going on; which should
> be the case at least during the initial EAP authentication).

Re: issues with scanning in mac80211

[Luis R. Rodriguez]

On Thu, Aug 26, 2010 at 1:47 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> Massaging this message a bit and putting it on the public
> mailing list.
>
> On Thu, Aug 26, 2010 at 01:14:36PM -0700, Amod Bodas wrote:
>> Thanks Jouni. Even my observations are same i.e I see 1 sec or
>> so scan before returning to home channel. Given background scan
>> issue looks to be mac80211 related.
>>
>> Who is lead scan module expert in the community?
>
> Well Helmut worked on it:
>
> Author: Helmut Schaa <Helmut.Schaa@gmx.de>
> Date:   Wed Feb 24 14:19:21 2010 +0100
>
>    mac80211: Improve software scan timing
>
>    The current software scan implemenation in mac80211 returns to the operating
>    channel after each scanned channel. However, in some situations (e.g. no
>    traffic) it would be nicer to scan a few channels in a row to speed up
>    the scan itself.
>
>    Hence, after scanning a channel, check if we have queued up any tx frames and
>    return to the operating channel in that case.
>
>    Unfortunately we don't know if the AP has buffered any frames for us. Hence,
>    scan only as many channels in a row as the pm_qos latency and the negotiated
>    listen interval allows us to.
>
>    Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
>    Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> but AFAICT the issues documented below were likely not considered into the
> architecture and its the first time I see them pointed out, unless I missed
> something. The above commit log shows only the pm_qos latency was taken
> into consideration, which I suppose can be modified for now as a hack
> to deal with these issues.

As suggested by Jouni, I'll test using min(listen_interval,
DTIM_PERIOD), this should only help with broadcast / multicast data
upon a scan. If there are any other thresholds required by userspace
this should likely be configured on the bg scan module I think.

  Luis

Re: issues with scanning in mac80211

[Luis R. Rodriguez]

On Thu, Aug 26, 2010 at 4:11 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> As suggested by Jouni, I'll test using min(listen_interval,
> DTIM_PERIOD), this should only help with broadcast / multicast data
> upon a scan. If there are any other thresholds required by userspace
> this should likely be configured on the bg scan module I think.

Ah bleh, we cannot rely on the dtim as it is not exposed to drivers
unless otherwise requested. This can be done by using the new
IEEE80211_HW_NEED_DTIM_PERIOD but this is completely unused by drivers
today.

mcgrof@tux ~/wireless-testing (git::master)$ git grep
IEEE80211_HW_NEED_DTIM_PERIOD drivers/net/wireless/
mcgrof@tux ~/wireless-testing (git::master)$


commit e5b900d228b76d445a4240d9aeb3cd8f79205a91
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Jul 29 16:08:55 2010 +0200

    mac80211: allow drivers to request DTIM period

    Some features require knowing the DTIM period
    before associating. This implements the ability
    to wait for a beacon in mac80211 before assoc
    to provide this value. It is optional since
    most likely not all drivers will need this.

    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

.... < amongst other hunks > ...

diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index cf8d721..b6c163a 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -870,6 +870,11 @@ static void ieee80211_set_associated(struct
ieee80211_sub_if_data *sdata,

        ieee80211_led_assoc(local, 1);

+       if (local->hw.flags & IEEE80211_HW_NEED_DTIM_PERIOD)
+               bss_conf->dtim_period = bss->dtim_period;
+       else
+               bss_conf->dtim_period = 0;
+
        bss_conf->assoc = 1;
        /*
         * For now just always ask the driver to update the basic rateset

Re: issues with scanning in mac80211

[Luis R. Rodriguez]

On Thu, Aug 26, 2010 at 4:35 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Thu, Aug 26, 2010 at 4:11 PM, Luis R. Rodriguez
> <lrodriguez@atheros.com> wrote:
>> As suggested by Jouni, I'll test using min(listen_interval,
>> DTIM_PERIOD), this should only help with broadcast / multicast data
>> upon a scan. If there are any other thresholds required by userspace
>> this should likely be configured on the bg scan module I think.
>
> Ah bleh, we cannot rely on the dtim as it is not exposed to drivers
> unless otherwise requested. This can be done by using the new
> IEEE80211_HW_NEED_DTIM_PERIOD but this is completely unused by drivers
> today.
>
> mcgrof@tux ~/wireless-testing (git::master)$ git grep
> IEEE80211_HW_NEED_DTIM_PERIOD drivers/net/wireless/
> mcgrof@tux ~/wireless-testing (git::master)$
>
>
> commit e5b900d228b76d445a4240d9aeb3cd8f79205a91
> Author: Johannes Berg <johannes.berg@intel.com>
> Date:   Thu Jul 29 16:08:55 2010 +0200
>
>    mac80211: allow drivers to request DTIM period
>
>    Some features require knowing the DTIM period
>    before associating. This implements the ability
>    to wait for a beacon in mac80211 before assoc
>    to provide this value. It is optional since
>    most likely not all drivers will need this.
>
>    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>    Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> .... < amongst other hunks > ...
>
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index cf8d721..b6c163a 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -870,6 +870,11 @@ static void ieee80211_set_associated(struct
> ieee80211_sub_if_data *sdata,
>
>        ieee80211_led_assoc(local, 1);
>
> +       if (local->hw.flags & IEEE80211_HW_NEED_DTIM_PERIOD)
> +               bss_conf->dtim_period = bss->dtim_period;
> +       else
> +               bss_conf->dtim_period = 0;
> +
>        bss_conf->assoc = 1;
>        /*
>         * For now just always ask the driver to update the basic rateset
>

Ah but this prior to association.. we stil should be setting it after assoc.

  Luis

Re: issues with scanning in mac80211

[Helmut Schaa]

Am Thursday 26 August 2010 schrieb Luis R. Rodriguez:
> Massaging this message a bit and putting it on the public
> mailing list.
> 
> On Thu, Aug 26, 2010 at 01:14:36PM -0700, Amod Bodas wrote:
> > Thanks Jouni. Even my observations are same i.e I see 1 sec or
> > so scan before returning to home channel. Given background scan
> > issue looks to be mac80211 related.
> >
> > Who is lead scan module expert in the community?
> 
> Well Helmut worked on it:
> 
> Author: Helmut Schaa <Helmut.Schaa@gmx.de>
> Date:   Wed Feb 24 14:19:21 2010 +0100
> 
>     mac80211: Improve software scan timing
>     
>     The current software scan implemenation in mac80211 returns to the operating
>     channel after each scanned channel. However, in some situations (e.g. no
>     traffic) it would be nicer to scan a few channels in a row to speed up
>     the scan itself.
>     
>     Hence, after scanning a channel, check if we have queued up any tx frames and
>     return to the operating channel in that case.
>     
>     Unfortunately we don't know if the AP has buffered any frames for us. Hence,
>     scan only as many channels in a row as the pm_qos latency and the negotiated
>     listen interval allows us to.
>     
>     Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
>     Signed-off-by: John W. Linville <linville@tuxdriver.com>
> 
> but AFAICT the issues documented below were likely not considered into the
> architecture and its the first time I see them pointed out, unless I missed
> something. 

The current implementation never intended to do proper DTIM beacon handling, it
is only considering unicast traffic. And it tries to stay away of the operating
channel as long as possible (listen_interfal & pm_qos latency). 

Changing that would require a bit of work. The delayed_work scheduling needs to
take into account when the next DTIM beacon is expected and we most likely need
to shorten the time for a passive channel based on the expected time we've got
left. Furthermore, we need to know how long the channel switch will take (we
had something like that but not anymore ...).

> The above commit log shows only the pm_qos latency was taken
> into consideration, which I suppose can be modified for now as a hack
> to deal with these issues.
> 
> Jouni's observations below.
> 
> > -----Original Message-----
> > From: Jouni Malinen 
> > Sent: Thursday, August 26, 2010 12:22 PM
> > To: Amod Bodas
> > Cc: Luis Rodriguez
> > Subject: Re: issues with scanning in mac80211
> > 
> > I do not know what is in compat-wireless, but at least the current
> > wireless-testing.git background scanning algorithm in mac80211 looks
> > pretty horrible from the view point of receiving broadcast frames from
> > the current AP. I'm actually getting much worse results..
> > My tests show 1020 ms away from operating channel vs. Sam's 175 ms.
> > 
> > mac80211 does not seem to even try to receive PS buffered
> > broadcast/multicast frames. It is only limiting the off-channel scan
> > operation based on listen interval (which is 10 with ath9k) which allows
> > it to miss ten beacon intervals in row from the current AP even if the
> > DTIM period is one..

Yes, correct. The mac80211 scan implementation does not honor broad- and
multicast traffic at all. It returns to the operating channel if tx
frames are pending, the qos latency was exceeded or the liste interval was
exceeded.

> > In addition, the time when it leaves the operating
> > channel is not synchronized with the beacons at all.

Correct.

Helmut

Re: issues with scanning in mac80211

[Helmut Schaa]

Am Friday 27 August 2010 schrieb Helmut Schaa:
> Am Thursday 26 August 2010 schrieb Luis R. Rodriguez:
> > Massaging this message a bit and putting it on the public
> > mailing list.
> > 
> > On Thu, Aug 26, 2010 at 01:14:36PM -0700, Amod Bodas wrote:
> > > Thanks Jouni. Even my observations are same i.e I see 1 sec or
> > > so scan before returning to home channel. Given background scan
> > > issue looks to be mac80211 related.
> > >
> > > Who is lead scan module expert in the community?
> > 
> > Well Helmut worked on it:
> > 
> > Author: Helmut Schaa <Helmut.Schaa@gmx.de>
> > Date:   Wed Feb 24 14:19:21 2010 +0100
> > 
> >     mac80211: Improve software scan timing
> >     
> >     The current software scan implemenation in mac80211 returns to the operating
> >     channel after each scanned channel. However, in some situations (e.g. no
> >     traffic) it would be nicer to scan a few channels in a row to speed up
> >     the scan itself.
> >     
> >     Hence, after scanning a channel, check if we have queued up any tx frames and
> >     return to the operating channel in that case.
> >     
> >     Unfortunately we don't know if the AP has buffered any frames for us. Hence,
> >     scan only as many channels in a row as the pm_qos latency and the negotiated
> >     listen interval allows us to.
> >     
> >     Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
> >     Signed-off-by: John W. Linville <linville@tuxdriver.com>
> > 
> > but AFAICT the issues documented below were likely not considered into the
> > architecture and its the first time I see them pointed out, unless I missed
> > something. 
> 
> The current implementation never intended to do proper DTIM beacon handling, it
> is only considering unicast traffic. And it tries to stay away of the operating
> channel as long as possible (listen_interfal & pm_qos latency). 
> 
> Changing that would require a bit of work. The delayed_work scheduling needs to
> take into account when the next DTIM beacon is expected and we most likely need
> to shorten the time for a passive channel based on the expected time we've got
> left. Furthermore, we need to know how long the channel switch will take (we
> had something like that but not anymore ...).

Oh, and that's gonna get a bit more difficult in scenarios with multiple STA
interfaces.