[rt2x00-users] [RFC v2] Add autowake support for USB hardware
js at sig21.net
Wed Apr 13 06:40:00 EST 2011
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.
> >> + 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.
> > Maybe that's good enough, but it should be mentioned in the
> > patch description.
> I am currently copying the behavior of the cart9170 driver, as I
> considered a nice
> basis to start with. It doesn't nesceserily have to be the final design. :)
OK, then I guess it's the right thing to do.
More information about the users