On Thu, 2009-07-16 at 11:50 +0200, Helmut Schaa wrote: > > Based on your initial description I thought it was going to be > > scanning == SW_SCANNING > > or > > scanning == SW_SCANNING | BG_SCANNING > > It's exactly the other way round :) > > It is either BG_SCANNING or SW_SCANNING | BG_SCANNING. > > I already thought that this might cause confusion but I think > BG_SCANNING better reflects that we are currently running a scan > (independant of the current scan state) whereas SW_SCANNING better > reflects that we are on a different channel for scanning. > > Maybe I should use other terms. Ideas? Ah, ok. Since your patch 4/5 changes sw_scanning to SW_SCANNING, I think at least change it to BG_SCANNING there already. OTOH, I think people are used to sw_scanning so it would be better to keep it. Maybe do SW_SCANNING and SW_SCANNING | OFF_CHANNEL or maybe SW_SCANNING | PROBING or something like that? > > Anyway looks pretty good to me! How does it fare during ping -f or > > something? > > I compared it to the hw_scan implementation of iwlwifi. We loose a few > more frames (I guess due to not flushing the queues before channel switch) > but it's not really much, it was <1% for ping -f). Yeah, we still need to add a queue flush callback for the hardware, but that can wait some more. > I didn't do much performance testing, just a single wget and the performance > dropped to about 50%. I still have to run some iperf tests (both RX and TX) to > see how it behaves. I'd be more interested in the rtt stats that ping -f prints after you abort it: rtt min/avg/max/mdev = 0.021/0.028/1.726/0.051 ms (this was on 127.0.0.1) johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
