ath9k/ath10k DFS testing / certification

[Jean-Pierre Tosoni]

> -----Message d'origine-----
> De : adrian.chadd at gmail.com [mailto:adrian.chadd at gmail.com] De la part de
> Adrian Chadd
> Envoyé : mardi 24 janvier 2017 18:42
> À : Jean-Pierre Tosoni
> Cc : ath10k at lists.infradead.org; Cedric VONCKEN
> Objet : Re: ath9k/ath10k DFS testing / certification
> 
> 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.

No, since we seldom have to conduct this test, we just made an on-site adjustment
on iperf arguments so we could pass.
> 
> Thanks,
> 
> 
> -adrian