John W. Linville wrote: > On Fri, May 11, 2007 at 01:24:58AM +0300, Tomas Winkler wrote: >> On 5/10/07, Jiri Benc <jbenc@xxxxxxx> wrote: >>> On Thu, 10 May 2007 13:17:12 -0700, jketreno wrote: > >>>> Generic algorithms aren't as capable as hardware specific algorithms >>>> when you factor performance, latency, system utilization, power >>>> consumption, etc. Optimal algorithms are written to take advantage of >>>> the capabilities exposed by the hardware. >>> You said the same about hardware scanning. Michael showed you that's >>> not true. >>> >> Michael has shortened the dwell time on the channel, while hw scanning >> has shorten switching time from the channel to channel and no the time >> you are listening on the channel >> I wouldn't call it an optimization. Did he measured the power consumption ? > > This was going to be my question, and I think it is a worthy point. :-) The scan "power savings" in question are so small as to not be measurable. The stack is only involved at the time it changes the channel... a few tens of us of CPU time over the multiple seconds of scan action... and the scan action itself only happens at long intervals. Is this really about commercial product differentiation? "Our hardware does faster 'hardware' scan" is good for Intel, even though the truth would more properly be expressed as "we took scan away from the open stack and put it in the closed source firmware binary blob where our implementation is a special modal thing that sooner or later will cause side effects, and there are space constraints and less of an OS API structure to lean on and the code is not reviewed". (I assume everyone who has used ipw3945 and even iwlwifi is familiar with MICROCODE ERROR and bad things arising from that.) And in the end as was pointed out beforehand, the scan implementation in the firmware is not measurably faster or more saving of power anyway. (While I was writing this the 3945 on this box lost association, and when I tried to reinsert the driver modprobe stalled and I see permanent 100% CPU usage on both cores. That's a genuine low hanging fruit for "powersaving" on iwl3945/iwlwifi ;-) ) >>> If the slowdown is not big, yes, it is. Unifying things almost always >>> means you need to accept some trade-offs. >> Clean API gives you the ability to enjoy from the both worlds. WiFi is >> about mobility power saving and therefore hw offloading is essential. Sexy-sounding "hw offloading" is a very different thing to migrating off open code and putting it in vendor-specific closed source firmware. The firmware is just code like any other, for an embedded ARM7 or similar, except that it is customized for a specific vendor hardware implementation and you will never see the sources. What I understand is being talked about (maybe unlike the scan stuff this actually is in hardware, but I doubt it) is ignoring code in the stack and instead implementing pretty much the same code privately, to compile to a binary blob you can't see source for or even reverse according to its license. That is a lot less romantic than mysterious hardware just waiting to be used. If we are far from the AP and only say 5.5Mbps rate packets get through, then there is presumably adaptation to that in the stack, it is not like it will sequence through 54Mbps -> 48Mbps -> ... 5.5Mbps each time, instead any effective rate limiting action will react to the situation by issuing mainly 5.5Mbps packets that get through first time and probing with faster packets occasionally to see if the situation was better. *Therefore any effective rate adaptation acts to limit any benefit that can come from tagging packets with rate lists in firmware as is proposed*. Put another way the meaning of rate limiting is to attempt to minimize effective airtime including the wasted restransmits at rates that never get through. So if there are excessive retransmits going on due to poor selection of tx rate for the circumstances (rather than interference) then isn't it better to address that in the stack so all devices can benefit from a smarter algorithm? (not least in recouping the wasted airtime and power used for TX that did not get through) Collecting numbers on the retransmit probability per packet for different environments would be interesting anyway aside from all this, allowing objective metrics on rate management performance, but you would think it would be an important element of making the decision to pursue doing all the work to tag packets with rate lists in the firmware. >> What worth the few more lines of the code that gives you this ability >> this is also a trade-off. > > Agreed. FWIW, power saving is worthwhile even for fixed stations as well. Anyone can propose anything and just slip the word patriot- er - powersaving in a few times. The true issue here is how much stuff that can and should be done in the open, shared stack are you willing to see in a vendor-specific binary blob (with support for the vendor-specific blobby APIs added to the stack) to get claimed advantages (eg, powersaving, scan speed) that aren't shown to hold water. I can imagine sometimes the benefits can be genuine and strong and you have to work with it, but the other times... -Andy - 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
