All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.