On Tue, 2009-03-24 at 16:17 +0200, Kalle Valo wrote: > > Therefore, I think the "power saving level" needs to be determined > > by pm_qos. The design of how to do that, however, is still up in the > > air. > > Maybe. At least it "feels" a lot better than the five magic numbers :) > > Unfortunately I haven't thought about this so I cannot comment on it. > And by the looks of it, I won't find the time for some time. By the way, do you have any numbers on how the timeout affects actual network latency? It's also related to the beacon interval and the listen interval, of course. > > The alternative would be to expose all the possible parameters and/or > > levels to mac80211 and have it make choices based on pm_qos, but it > > seems that this interface would rapidly become extremely complex, > > fragile and buggy. > > I think this alternative would be better in the long run. My feeling > is that the settings between different hardware don't wary that much > based on what I have seen and we would eventually find settings which > work for all, maybe small hackery needed somewhere but that's it. I'm just worried that we'll require a whole bunch of different interfaces. Yes, in theory there isn't much to control, but iwlwifi firmware for example can, as far as I interpret the code, dynamically vary the listen interval. Some of the decisions might also depend on the hardware, I could imagine, the point where turning off power saving is required might be different depending on hardware due to wakeup time maybe? > Also remember that in !IEEE80211_HW_SUPPORTS_DYNAMIC_PS case the > dynamic timer is in mac80211. So the driver cannot make all decisions. Right. > > Kalle, there's a related question here -- what's the value of exposing > > the sleep timeout to users? It seems to be quite unnecessary, since you > > seem to be using a fixed value of 500ms anyway. > > In Maemo products (n800, n810 etc) we use it to select the power save > aggressiveness. IIRC in diablo it was so that when the display was on > 200 ms timeout value was used, and then it was off the value was set > to 100 ms. The decision was made in userspace, in wlancond (our dbus > WE wrapper). The idea here was that user won't most probably mind if > the network is slower then the display is off. > > > Can we remove that, leaving wext only with turning on/off power > > saving? [2][3] > > I would hate to loose it, at least in the near future. If there's a > good alternative and a proper deprecation period, I don't mind it > going away. The trivial alternative would be to use /dev/network_latency and register the requirements instead, but do it "globally" based on display state rather than "properly" based on applications. > Disabling the power save should always be a visible option for the > users because of the broken APs. There are still APs which have > problems with power save enabled clients. Ok. > > However, by putting the burden onto drivers, drivers can choose a > > conservative power saving level when no application has registered its > > pm_qos requirements, and once applications start using the it deeper > > power levels can be chosen as appropriate. > > It will take years for the applications to adapt this, I would not > want to depend on that. I would like to have usable already without > application support. As I said above, you can always have a single application register requirements for the other apps. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
