On Thu, 2010-04-22 at 11:55 +0300, Juuso Oikarinen wrote: > > > Well you have to see where I'm coming from - I must come up with a way > > > to tune the dynamic ps timeout value from user-space in a way that is > > > agreeable with others, and that is somewhat future-proof. > > > > Well I personally think that's your first mistake ;) > > > > Why does userspace care about the dynamic PS timeout value to start > > with? All it should care about is the latency with which it can react to > > network packets, no? > > > > > That said, obviously the network latency should be tuned as, well, the > > > expected network latency. In this phase though, there are no other > > > parameters affected by the network latency, so the result is quite > > > obvious - your fear will realise itself ;) > > > > But there are, like the max sleep period in # of beacons. > > Yeah, okay there is. You probably noticed I posted a version of the > patches with "saner" latency-values for this reason. 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? 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
