On Thu, 2010-04-22 at 12:29 +0300, Juuso Oikarinen wrote: > > Still I think you should say why you need to actually tune the PS > > timeout value directly? I can't see how your high-level design says "set > > dynamic PS timeout to 100ms" rather than "make sure that while the user > > is operating the device, there's no delay of more than 50ms" or > > something like that? > > You're partly right asking this. The high-level design obviously does > not know about dynamic PS timeouts. It seems you're mainly looking at > this from the angle of the network latency itself - i.e. network > performance. My primary angle currently is power consumption. > > IMHO both angles are correct. The if the user sets a tight > network-latency requirement, the value can be used to tune things so > that the requirement can be met. If they set a loose requirement, it can > be used as a signal to do more aggressive power saving, which often > means reduced latency. Well I would argue that if the user requires a certain network latency, that should take precedence. The user is unlikely to be thinking in terms of "I want my battery to last that long"; rather they want to last it as long as possible given their quality of service demand constraints? > While the mechanism I'm proposing here is rather crude, it does save > power when the user-space loosens their latency requirement. The values > chosen for the dynamic ps-timeout bear no direct relation to user space > requirements. They are simply values that we have found to give decent > results in typical AP configurations. > > The ps_timeout could be calculated based on the latency too, I guess. > I'm just not aware of any simple formula to do this. But you did just base it on that? It just seems to me that you're putting the power consumption requirements after the quality of service demands, which would seem wrong? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
