ath9k/ath10k DFS testing / certification

[Adrian Chadd]

On 24 January 2017 at 08:52, Jean-Pierre Tosoni <jp.tosoni at acksys.fr> wrote:
>
>
>> -----Message d'origine-----
>> De : ath10k [mailto:ath10k-bounces at lists.infradead.org] De la part de
>> Adrian Chadd
>> Envoyé : mardi 24 janvier 2017 17:27
>> À : Jean-Pierre Tosoni
>> Cc : ath10k at lists.infradead.org; Cedric VONCKEN
>> Objet : Re: ath9k/ath10k DFS testing / certification
>>
>> On 24 January 2017 at 06:53, Jean-Pierre Tosoni <jp.tosoni at acksys.fr>
>> wrote:
>> >
>> >> -----Message d'origine-----
>> >> De : ath10k [mailto:ath10k-bounces at lists.infradead.org] De la part de
>> >> Adrian Chadd Envoyé : lundi 16 janvier 2017 18:43 À : Jean-Pierre
>> >> Tosoni Cc : Cedric VONCKEN; ath10k at lists.infradead.org Objet : Re:
>> >> ath9k/ath10k DFS testing / certification
>> >>
>> >> hiya,
>> >>
>> >> Yeah - i was a part of that discussion. :) That's why I was pointing
>> >> out that likely I'm going to bug QCA to get this fixed when the time is
>> right.
>> >>
>> >> So, time is right :)
>> >>
>> >> Did you do DFS certification for AP/master devices, or just client?
>> >
>> > We did it for both AP and client modes.
>> > We had the same problem with IPERF than Simon, and we solved that by
>> defining a huge packet size and IPERF would send it every now and then
>> just enough to meet the throughput required.
>>
>> The traffic duty cycle stuff was always a pain to get "right" when I was
>> last doing this (pre ath10k hardware.)
>>
>> Is this just for your local testing, or is this something the testing
>> house / FCC / etc defines?
>
> FCC I don't know, I'm concerned with ETSI ;)
> We used that at an external lab, and they verified that we complied with the
> 30% over 100ms requirement (see below).
>
> ETSI EN 301 893 defines a specific burst requirement for DFS testing, to quote it:
>   "...shall consist of packet transmissions that together exceed the transmitter
>   minimum activity ratio of 30 % measured over an interval of 100 ms..."
>
> The requirement is not really picky, it could be one mega-frame after every beacon or such.
> If we uses too much throughput or tightly sequenced frames, the radar signatures would be lost among the data frames.
>
> (Other tests (not about DFS) have more stringent requirements, e.g. 10% bandwidth
> over periods of 2ms)
>>
>> (Yes, I know about the traffic duty cycle definitions in the FCC spec and
>> how that changed over time, but I also remember how different
>> locations/labs had subtly different testing setups with different "bursty"
>> traffic.)
>>
> We made the setup and the lab checked that it was within the norm requirements.

ok!

Did you (or anyone else) tweak the quiet time configuration whilst
doing DFS master mode testing?

Maybe doing some tweaks like "maximum aggregation frame length",
"maximum burst length", "quiet time", etc could make the AP side
transmitter work without hacking on iperf, etc.

Thanks,


-adrian