Michael, 1) Saving 18 seconds of busy system will provide you much more time of idle system. So the benefit is much more than 18 seconds per hour. The calculation that you gave below is just incorrect. 2) CPU utilization/Power is a big deal for handheld devices. We can't ignore it. Linux is gaining momentum in small factor devices and we need to welcome any HW acceleration. The point that it is implemented in FW doesn't change the fact that this is a HW offloading from the host. 3) Sending Tune command for every channel from the stack when a HW is capable of doing so, doesn't make sense. The latency and overhead is redundant and will impact user experience (e.g. a [longer] glitch in Video streaming, shorter battery life). Guy. On 4/27/07, Michael Wu <flamingice@xxxxxxxxxxxx> wrote:
Ok. Since you did not provide any numbers to back up that assertion, let's try to find the upper bound for the cost of using software scanning. With NetworkManager, userspace requests a scan about every 2 minutes when connected. Assume that each scan takes 3 seconds. Assume that things are ridiculously inefficient and software scanning keeps the cpu on for an additional 20% of the scanning time. This keeps the CPU on unnecessarily for 18 seconds every hour, assuming nothing else is running. With an additional assumption that all the additional CPU time that goes into software scan directly subtracts from the battery life, this results in a loss of about 2 minutes and a half of battery life.. for a laptop that can last 8 hours. An upper bound of 18 seconds of battery life lost per hour sounds okay to me especially when it assumes the user is just letting the laptop idle. In practice, I think that the difference is going to be negligible.. but what I think is going to happen and my guess at the upper bound doesn't matter much. If you can provide numbers, this discussion becomes significantly more productive. -Michael Wu
- 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
