On Wed, 2008-11-05 at 23:25 +0200, Kalle Valo wrote: > > Well if you add a monitor interface you may want to turn off PS, > > Ok, now I got it. I think your proposal makes sense. > > > but I suppose you can just do that on the wlan0 interface you're > > associated on. > > Yeah, but that's an extra hassle. In my opinion better to do it in > mac80211. Yeah but you don't _always_ want it, I'd like to keep a monitor mode that doesn't influence the operation at all and just shows what mac80211 is getting from the driver. Hence thinking a monitor flag would be appropriate. > > Hmm. I suppose then we'd have to defer the actual disable PS mode to > > a work struct. > > Yes, that's what I was thinking. But now that I have thought about > this more, I think queueing of the frames is not necessary. The first > frames can be sent while in Power Save mode (ie. PSM bit set in Frame > Control) and PS disable can happen later when the work struct is > scheduled. I don't think this being a problem, we just have to be > careful with race conditions. We may need to send a nullfunc frame then. > > Maybe we don't want to disable PS for a single frame though > > Actually I think we do. The reason why I'm interested in dynamic PS is > the receive latency (transmit latency minimal is in practise). For > example, let's think about DNS request. In the best scenario only one > frame is transmitted, and if we don't come out receiving the reply to > the dns request will take a long time. If DTIM is 3 and beacon > interval 100 ms, the RTT for the DNS request/reply would be 300 ms. > That's a long delay to a case where user has pressed a link in the > browser and the browser starts to load a web page. Good point. So set my M to 1 and N to 0 ;) Well, in that case you don't need a timer at all but can just schedule the work right away. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
