[ath9k-devel] doubt regarding Hardware PHY counters

[ath9k-devel] doubt regarding Hardware PHY counters

[abhinav narain]

hi,

I am looking at the hardware counters for PHY ERRS in driver.
The OFDM counters are incremented as usual, but only one CCK counter is
incremented
(for one interface phy0 i suppose) and the other is always 0.

Seeing at the code in ani.c, it looks symmetric for ofdm,cck ... and I
can't figure out if this is
intentional or its some bug.
Please suggest whats the reason.

Also, I see the antenna (on which a packet is received) reported by ath9k
is usually 0.
Sometimes, the output fluctuates between 0 and 1 as expected, but I don't
find why its stuck to 1 most of the time.
I wanted to know if its fine, whatever I observed or there is any issue.

Abhinav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20120509/eeaedaad/attachment.htm 

[ath9k-devel] doubt regarding Hardware PHY counters

[Adrian Chadd]

Hi,

On 9 May 2012 12:13, abhinav narain <abhinavnarain10@gmail.com> wrote:
> hi,
>
> I am looking at the hardware counters for PHY ERRS in driver.
> The OFDM counters are incremented as usual, but only one CCK counter is
> incremented
> (for one interface phy0 i suppose) and the other is always 0.

"one CCK counter" ? Which registers are you looking at? Or which value?
are you looking at the AR_PHY_ERR_CNT_1/ AR_PHY_ERR_CNT_2 registers,
or are you looking at the results of counting phyerr's that are RXed ?

> Seeing at the code in ani.c, it looks symmetric for ofdm,cck ... and I can't
> figure out if this is
> intentional or its some bug.
> Please suggest whats the reason.
>
> Also, I see the antenna (on which a packet is received) reported by ath9k is
> usually 0.
> Sometimes, the output fluctuates between 0 and 1 as expected, but I don't
> find why its stuck to 1 most of the time.
> I wanted to know if its fine, whatever I observed or there is any issue.

11n NICs don't do antenna selection like previous NICs.

* for single chain NICs, it will always receive on chain 0;
* for dual/tri chain NICs, it will (almost) always receive on all
chains and do combining (this may vary for CCK, I'm not sure);
* for single chain, dual antenna NICs (eg AR9285), there's a pair of
LNAs and a configurable mixer (doing LNA1, LNA2, LNA1+LNA2, LNA1-LNA2,
LNA2-LNA1) which implements RX mixing _and_ classic antenna diversity.
Part of the RX completion information includes the above, but it's not
exported via the "RX antenna" API you're seeing. (It's partially
exposed in the AR9285 combined diversity code in ath9k, which is why I
can describe it here.)

HTH,


Adrian

[ath9k-devel] doubt regarding Hardware PHY counters

[abhinav narain]

>
>
> "one CCK counter" ? Which registers are you looking at? Or which value?
> are you looking at the AR_PHY_ERR_CNT_1/ AR_PHY_ERR_CNT_2 registers,
>
I am making it simple by taking the values in ath_rx_tasklet()
from
ah->stats.ast_ani_ofdmerrs , ah->stats.ast_ani_cckerrs
accumulators....
I see all them increasing except for one


> or are you looking at the results of counting phyerr's that are RXed ?
>
> I am looking at the PHY_RXERR, after I enabled, again through the counters
maintained by ath_softc
sc->debug.stats.rxstats.phy_err

Can I get a documentaion of what they mean somewhere .. I din't get much
through the code .


The tasklet runs in two different context for each of the radio and hence I
get the counters
for both the interfaces.

> Seeing at the code in ani.c, it looks symmetric for ofdm,cck ... and I
> can't
> > figure out if this is
> > intentional or its some bug.
> > Please suggest whats the reason.
> >
> > Also, I see the antenna (on which a packet is received) reported by
> ath9k is
> > usually 0.
> > Sometimes, the output fluctuates between 0 and 1 as expected, but I don't
> > find why its stuck to 1 most of the time.
> > I wanted to know if its fine, whatever I observed or there is any issue.
>
> 11n NICs don't do antenna selection like previous NICs.
>
> * for single chain NICs, it will always receive on chain 0;
> * for dual/tri chain NICs, it will (almost) always receive on all
> chains and do combining (this may vary for CCK, I'm not sure);
> * for single chain, dual antenna NICs (eg AR9285), there's a pair of
> LNAs and a configurable mixer (doing LNA1, LNA2, LNA1+LNA2, LNA1-LNA2,
> LNA2-LNA1) which implements RX mixing _and_ classic antenna diversity.
> Part of the RX completion information includes the above, but it's not
> exported via the "RX antenna" API you're seeing. (It's partially
> exposed in the AR9285 combined diversity code in ath9k, which is why I
> can describe it here.)
>

Thanks for this details, this helps a lot.
I am developing for netgear wndr 3700v2, but not quite sure which NIC it
uses.
I suppose I will just agree with what the output is saying.

-Abhinav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20120510/47ffb3e3/attachment.htm 

[ath9k-devel] doubt regarding Hardware PHY counters

[abhinav narain]

On Thu, May 10, 2012 at 6:49 PM, abhinav narain
<abhinavnarain10@gmail.com>wrote:

>
>> "one CCK counter" ? Which registers are you looking at? Or which value?
>> are you looking at the AR_PHY_ERR_CNT_1/ AR_PHY_ERR_CNT_2 registers,
>>
> I am making it simple by taking the values in ath_rx_tasklet()
> from
> ah->stats.ast_ani_ofdmerrs , ah->stats.ast_ani_cckerrs
> accumulators....
> I see all them increasing except for one
>
>
>> or are you looking at the results of counting phyerr's that are RXed ?
>>
>> I am looking at the PHY_RXERR, after I enabled, again through the
> counters maintained by ath_softc
> sc->debug.stats.rxstats.phy_err
>
> Can I get a documentaion of what they mean somewhere .. I din't get much
> through the code .
>
>
> The tasklet runs in two different context for each of the radio and hence
> I get the counters
> for both the interfaces.
>
>  > Seeing at the code in ani.c, it looks symmetric for ofdm,cck ... and I
>> can't
>> > figure out if this is
>> > intentional or its some bug.
>> > Please suggest whats the reason.
>> >
>> > Also, I see the antenna (on which a packet is received) reported by
>> ath9k is
>> > usually 0.
>> > Sometimes, the output fluctuates between 0 and 1 as expected, but I
>> don't
>> > find why its stuck to 1 most of the time.
>> > I wanted to know if its fine, whatever I observed or there is any issue.
>>
>> 11n NICs don't do antenna selection like previous NICs.
>>
>> * for single chain NICs, it will always receive on chain 0;
>> * for dual/tri chain NICs, it will (almost) always receive on all
>> chains and do combining (this may vary for CCK, I'm not sure);
>> * for single chain, dual antenna NICs (eg AR9285), there's a pair of
>> LNAs and a configurable mixer (doing LNA1, LNA2, LNA1+LNA2, LNA1-LNA2,
>> LNA2-LNA1) which implements RX mixing _and_ classic antenna diversity.
>> Part of the RX completion information includes the above, but it's not
>> exported via the "RX antenna" API you're seeing. (It's partially
>> exposed in the AR9285 combined diversity code in ath9k, which is why I
>> can describe it here.)
>>
>
> Thanks for this details, this helps a lot.
> I am developing for netgear wndr 3700v2, but not quite sure which NIC it
> uses.
> I suppose I will just agree with what the output is saying.
>
> Found out, its AR 9280


> -Abhinav
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20120510/3aad1fdb/attachment.htm 

[ath9k-devel] doubt regarding Hardware PHY counters

[Adrian Chadd]

Hi,

So look at how those values are incremented.

* THey may be incremented from AR_PHY_CNT_{1,2} - see how that's setup
in ani.c and ar5008_phy.c
* They may be incremneted based on RX PHY errors in RX descriptors -
that's enabled by AR_PHY_ERR which is a bitmask of which phy errors to
pass through as RX descriptors (one completed descriptor per phy
error.)

HTH!


Adrian

[ath9k-devel] doubt regarding Hardware PHY counters

[abhinav narain]

hi,
 I checked out the code ...
Its the same code which executes in two different contexts of each radio.
radio 1 has all the values (ofdm, cck)
while radio 0 has ofdm only. cck =0. I couldn't find out where exactly the
difference lies (might be in hardware ? )

There is one other thing :
There are some numbers (magic values)
AR_PHY_ERR_1           0x812c
AR_PHY_ERR_MASK_1      0x8130

AR_PHY_ERR_2           0x8134
AR_PHY_ERR_MASK_2      0x8138

Why are they set to above value and not something else ?
Are they corresponding to two disjoint set of errors ? or some other reason
?

The following two macros are used for the ofdm, cck hardware counters.
AR_PHY_ERR_OFDM_TIMING
AR_PHY_ERR_CCK_TIMING

Can you please tell what do they mean /what kind of error do they relate to
?

There are certain frames with zero byte size, and certain frames with zero
bytes size and PHY_ERR (this phy error is corresponding to the DMA ones.).
whats the difference between two such frames ?
this is in the ath9k_rx_accept() with condition rs->datalen ==0
(I don't think they are accounted for anywhere in the driver, the phy error
ones are )

I couldn't understand the purpose/usage of ofdmNoiseImmunityLevel,
cckNoiseImmunityLevel, ofdmErrRssi
used in struct ar5416AniState{} , for AR9280.

-Abhinav








On Fri, May 11, 2012 at 12:03 AM, Adrian Chadd <adrian@freebsd.org> wrote:

> Hi,
>
> So look at how those values are incremented.
>
> * THey may be incremented from AR_PHY_CNT_{1,2} - see how that's setup
> in ani.c and ar5008_phy.c
> * They may be incremneted based on RX PHY errors in RX descriptors -
> that's enabled by AR_PHY_ERR which is a bitmask of which phy errors to
> pass through as RX descriptors (one completed descriptor per phy
> error.)
>
> HTH!
>
>
> Adrian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20120516/cd97d937/attachment.htm 

[ath9k-devel] doubt regarding Hardware PHY counters

[Adrian Chadd]

Hi,

So there are two error counters which count PHY errors. The mask
register controls which events trigger that counter.
So AR_PHY_ERR_1 is counter 1, AR_PHY_ERR_MASK_1 is the mask regiser
for AR_PHY_ERR_1 which controls which PHY errors increment that
counter.
Same for _2.

Hm, they're in different spots - maybe pre-AR9300 versus AR9300 and
later? I know that the AR9300 and later shifted around a whole lot of
registers.

You shouldn't see any valid data RX frames with a datalen=0; you
should only see PHY errors. Please provide details if that's not the
case. :)

For the ANI related parameters, please visit the patent documentation.
I have it linked off of this page:
http://wiki.freebsd.org/dev/ath_hal%284%29/AutomaticNoiseImmunity


Adrian

On 15 May 2012 22:29, abhinav narain <abhinavnarain10@gmail.com> wrote:
> hi,
> ?I checked out the code ...
> Its the same code which executes in two different contexts of each radio.
> radio 1 has all the values (ofdm, cck)
> while radio 0 has ofdm only. cck =0. I couldn't find out where exactly the
> difference lies (might be in hardware ? )
>
> There is one other thing :
> There are some numbers (magic values)
> AR_PHY_ERR_1 ? ? ? ? ? 0x812c
> AR_PHY_ERR_MASK_1 ? ? ?0x8130
>
> AR_PHY_ERR_2 ? ? ? ? ? 0x8134
> AR_PHY_ERR_MASK_2 ? ? ?0x8138
>
> Why are they set to above value and not something else ?
> Are they corresponding to two disjoint set of errors ? or some other reason
> ?
>
> The following two macros are used for the ofdm, cck hardware counters.
> AR_PHY_ERR_OFDM_TIMING
> AR_PHY_ERR_CCK_TIMING
>
> Can you please tell what do they mean /what kind of error do they relate to
> ?
>
> There are certain frames with zero byte size, and certain frames with zero
> bytes size and PHY_ERR (this phy error is corresponding to the DMA ones.).
> whats the difference between two such frames ?
> this is in the?ath9k_rx_accept() with condition rs->datalen ==0
> (I don't think they are accounted for anywhere in the driver, the phy error
> ones are )
>
> I couldn't understand the purpose/usage of?ofdmNoiseImmunityLevel,
> cckNoiseImmunityLevel,?ofdmErrRssi
> used in struct ar5416AniState{} , for AR9280.
>
> -Abhinav
>
>
>
>
>
>
>
>
> On Fri, May 11, 2012 at 12:03 AM, Adrian Chadd <adrian@freebsd.org> wrote:
>>
>> Hi,
>>
>> So look at how those values are incremented.
>>
>> * THey may be incremented from AR_PHY_CNT_{1,2} - see how that's setup
>> in ani.c and ar5008_phy.c
>> * They may be incremneted based on RX PHY errors in RX descriptors -
>> that's enabled by AR_PHY_ERR which is a bitmask of which phy errors to
>> pass through as RX descriptors (one completed descriptor per phy
>> error.)
>>
>> HTH!
>>
>>
>> Adrian
>
>

[ath9k-devel] doubt regarding Hardware PHY counters

[abhinav narain]

> So there are two error counters which count PHY errors. The mask
> register controls which events trigger that counter.
> So AR_PHY_ERR_1 is counter 1, AR_PHY_ERR_MASK_1 is the mask regiser
> for AR_PHY_ERR_1 which controls which PHY errors increment that
> counter.
> Same for _2.
>
Okay.
My question was more on the lines, instead of 0x812c .. why not 0xffff
will setting both the counters to 0xffff cause double counting ?
This is unreasonable to ask you in very detail, but is it that 0x812 refer
to the PHYERR which are given by the hardware capability as of now or any
other reason ?

>
> Hm, they're in different spots - maybe pre-AR9300 versus AR9300 and
> later? I know that the AR9300 and later shifted around a whole lot of
> registers.
>
Yes, but these masks are specifically used for counter incrementing, I was
curious to know if they only contribute to interference in wireless ?
Where can i find document explaining what error(as in packet came but the
hardware was not able to demodulate the signal due to timing problems or
what else, how to interpret them will be a better way to ask question ) do
they refer to ?


>
> You shouldn't see any valid data RX frames with a datalen=0; you
> should only see PHY errors. Please provide details if that's not the
> case. :)
>
I don't think I can see zero length , perhaps case of packet size (0,4)
range is there which is came to me as surprising as 4 bytes of FCS must be
always there in packet.

The point i was wondering about is :
The frame had no PHY errors and yet it was of length zero !
Any reason about why is it so, because any frame that was trasmitted will
be of length >zero and if there are no PHY errors in capturing by hardware,
why will its length goto zero ?


> For the ANI related parameters, please visit the patent documentation.
> I have it linked off of this page:
> http://wiki.freebsd.org/dev/ath_hal%284%29/AutomaticNoiseImmunity
>
> I see, helped me in knowing about ani. Thanks !


>
> Adrian
>
> On 15 May 2012 22:29, abhinav narain <abhinavnarain10@gmail.com> wrote:
> > hi,
> >  I checked out the code ...
> > Its the same code which executes in two different contexts of each radio.
> > radio 1 has all the values (ofdm, cck)
> > while radio 0 has ofdm only. cck =0. I couldn't find out where exactly
> the
> > difference lies (might be in hardware ? )
> >
> > There is one other thing :
> > There are some numbers (magic values)
> > AR_PHY_ERR_1           0x812c
> > AR_PHY_ERR_MASK_1      0x8130
> >
> > AR_PHY_ERR_2           0x8134
> > AR_PHY_ERR_MASK_2      0x8138
> >
> > Why are they set to above value and not something else ?
> > Are they corresponding to two disjoint set of errors ? or some other
> reason
> > ?
> >
> > The following two macros are used for the ofdm, cck hardware counters.
> > AR_PHY_ERR_OFDM_TIMING
> > AR_PHY_ERR_CCK_TIMING
> >
> > Can you please tell what do they mean /what kind of error do they relate
> to
> > ?
> >
> > There are certain frames with zero byte size, and certain frames with
> zero
> > bytes size and PHY_ERR (this phy error is corresponding to the DMA
> ones.).
> > whats the difference between two such frames ?
> > this is in the ath9k_rx_accept() with condition rs->datalen ==0
> > (I don't think they are accounted for anywhere in the driver, the phy
> error
> > ones are )
> >
> > I couldn't understand the purpose/usage of ofdmNoiseImmunityLevel,
> > cckNoiseImmunityLevel, ofdmErrRssi
> > used in struct ar5416AniState{} , for AR9280.
> >
> > -Abhinav
> >
> >
> >
> >
> >
> >
> >
> >
> > On Fri, May 11, 2012 at 12:03 AM, Adrian Chadd <adrian@freebsd.org>
> wrote:
> >>
> >> Hi,
> >>
> >> So look at how those values are incremented.
> >>
> >> * THey may be incremented from AR_PHY_CNT_{1,2} - see how that's setup
> >> in ani.c and ar5008_phy.c
> >> * They may be incremneted based on RX PHY errors in RX descriptors -
> >> that's enabled by AR_PHY_ERR which is a bitmask of which phy errors to
> >> pass through as RX descriptors (one completed descriptor per phy
> >> error.)
> >>
> >> HTH!
> >>
> >>
> >> Adrian
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20120518/f4207084/attachment.htm 

[ath9k-devel] doubt regarding Hardware PHY counters

[Adrian Chadd]

Hi,

What register value are you asking about? Which register, and which
value is being written to which register?



Adrian