[rt2x00-users] [RFC v2] Add autowake support for USB hardware

[Ivo Van Doorn]

Hi.

> On Tue, Apr 12, 2011 at 09:17:02PM +0200, Ivo Van Doorn wrote:
>> > On Mon, Apr 11, 2011 at 09:18:44PM +0200, Ivo van Doorn wrote:
>> >> Please review carefully, during my ping test I got 3% packet loss which is quite reasonable
>> >> in my testing environment. Compared to v1 I got a big improvement in the ping times,
>> >> basically it was mostly 4ms (which matches my atheros card with PS enabled, or my rt2800usb
>> >> stick with PS disabled). However at some times I got ping times of 64ms for a few seconds, before
>> >> it dropped back to 4ms again.
>> >
>> > Since the traffic is buffered during power save I think it is normal
>> > to get ping times up to the DTIM period?  I'm not sure how the
>> > Atheros card manages to get low ping times during PS.  Maybe the
>> > Atheros cards stays awake a while after TX before going to sleep,
>> > in case there are replies. You should be able to see in traffic dump
>> > when the STA sets the PS bit in the frame control field.
>>
>> Yeah, I also expected delays, but basically without this patch I get
>> ping times of 64ms,
>> with the patch, I would expect a improvement in the performance. ;)
>
> In which direction do you do the ping?  STA to AP?  I think the current
> code fails when you ping from AP to STA (STA doesn't wake up in time,
> I think STA to STA via AP is the same case),
> so that's where we should see an improvement from your patch.

I was pinging STA to AP, I'll try testing with some other variations as well.

>> >> +             queue_delayed_work(rt2x00dev->workqueue,
>> >> +                                &rt2x00dev->autowakeup_work,
>> >> +                                msecs_to_jiffies(rt2x00dev->beacon_int) - 1);
>> >
>> > This fixed delay assumes rt2x00lib_config() is always called right
>> > after the beacon and not e.g. in the middle of the beacon interval.
>> > But is this the case if there is a sufficient amount of traffic?
>>
>> Well is there a way to tell how much time is left until the next beacon?
>
> When I experimented with the hrtimer thing for AP mode I found
> that on rt2800usb you can read the TBTT_TIMER register, which
> counts down to 0 in 64us units.

Ok, so I should update this calculation to do something like:

((dtim_period - 1) * beacon_int) +  TBTT_TIMER

Or should I check the max_sleep_period field in the ieee80211_conf structure?

Ivo