On Friday 27 April 2007 00:14, James Ketrenos wrote: > If done right, the stack would set up the list of channels to scan, whether > to scan the channel active or passive, and the template for the probe > request to use. > > For sw based scans, the stack would then have a mechanism for executing > that scan through a series of tunes, transmits, etc. For hw scans, it > would pass that structure to the driver which would package it for the > hardware and pass it down. > > Upon completion of the scan (sw or hw) the notification would come back to > the stack to let it know scanning is complete. > Yes, this addresses many of the deficiencies in the current hw_scan api, but that wasn't what I was concerned about. > > What's the big bottleneck that justifies moving this to > > hardware? > > With the 3945 its mainly power consumption. > 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
Attachment:
pgpvEdALpKO6r.pgp
Description: PGP signature
