repost, unintentionally removed linux-wireless from CC On 03/06/2015 01:32 PM, Henning Rogge wrote: > 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? > 'unacceptable' is relative ;) Regulatory requires you to detect reference patterns with only 50% of the pulses seen. Take e.g. ETSI pattern 1 which has 10 nominal pulses, i.e. your detector must be capable to detect any combination of 5 pulses within an presumed interval as radar. If you have enough noise or WLAN traffic on proximate channels, there is no way to differentiate between false and true positives. >> 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... > It is. Our company is developing systems that not only get certified for DFS operation, but also provide a reliable and continuous service on DFS channels. The effort required is enormous. > >> 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? > > No, it is a generic problem of distinguishing radar pulses from any other type of interferences. This is a problem at physical layer and should be common to all WLAN devices out there, no matter if the DFS detection is done in HW, FW, or SW. We are using ath9k for that specific reason: we can't do much about the pulse detection in HW, but at least we have control over the pattern detector and can tweak the detection parameters to tune sensitivity. Cheers, Zefir -- 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
