On Fri, Mar 6, 2015 at 1:24 PM, Zefir Kurtisi <zefir.kurtisi@xxxxxxxxxxx> wrote: > On 03/06/2015 09:04 AM, Henning Rogge wrote: >> [...] >> >> Second, we are seeing a huge amount of radar events on some nodes, but >> not on a node on the same channel in the next room. What is the status >> of the DFS detector in ath9k, is it reliable or is it still >> "experimental". >> > > Henning, > > the DFS detector on one hand still can be labeled as 'experimental' since it seems > to be not used / tested all too much. On the other hand, our company got it > DFS-ETSI certified for a ath9k based product - so it does what it was made for. > > As for the 'false' radar detections you observe: those are inherent for the > detection method used. The ath9k's pulse detection engine reports anything that > somewhat looks like a radar pulse - besides very rare cases where those were > generated by real radar, most of them are EM-noise, WLAN traffic, other radio devices. This means that the DFS algorithm produce an unacceptable (for mesh networks) amount of false positives, right? > Reality check: let two APs operate close to each other on adjacent DFS-channels, > connect one station to one of them and generate continuous downstream traffic > (e.g. 10Mbps). It will take only seconds until the other AP will detect a radar - > simply because it is inevitable to spot some potential pattern within a lot of > random pulses. This is bad... > If you performed the tests in a similar environment, your observation is what you > have to expect. And unfortunately there is nothing to be done to prevent the false > radar detections - rendering operation on DFS frequencies inapplicable under some > environmental conditions. Is this just a problem of the Linux Kernel implementation? Or is this a problem of all wifi drivers? Henning Rogge -- 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
