From: Zefir Kurtisi <zefir.kurtisi@neratec.com>
To: Henning Rogge <hrogge@gmail.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: State of DFS with Mac80211/ath9k
Date: Fri, 06 Mar 2015 13:24:59 +0100 [thread overview]
Message-ID: <54F99C9B.7000901@neratec.com> (raw)
In-Reply-To: <CAGnRvurPGf1fvYs6fyrc7kttT8g3+ST_3mO5P6+mwdbU4Ay7yA@mail.gmail.com>
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.
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.
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.
Cheers,
Zefir
next prev parent reply other threads:[~2015-03-06 12:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-06 8:04 State of DFS with Mac80211/ath9k Henning Rogge
2015-03-06 8:38 ` Janusz Dziedzic
2015-03-06 9:26 ` Henning Rogge
2015-03-06 12:29 ` Janusz Dziedzic
2015-03-06 12:50 ` Jouni Malinen
2015-03-06 12:54 ` Henning Rogge
2015-03-06 13:00 ` Jouni Malinen
2015-03-06 12:24 ` Zefir Kurtisi [this message]
2015-03-06 12:32 ` Henning Rogge
2015-03-06 15:36 ` Zefir Kurtisi
[not found] ` <54F9A41F.4090505@neratec.com>
[not found] ` <CAGnRvuqpD6YHS6wJFR5J3n0sQqM3cfKYcydE4wYE52eiZjZeDA@mail.gmail.com>
[not found] ` <54F9C7B1.3090406@neratec.com>
2015-03-07 8:33 ` Henning Rogge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54F99C9B.7000901@neratec.com \
--to=zefir.kurtisi@neratec.com \
--cc=hrogge@gmail.com \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.