[ath9k-devel] AR9280 - OFDM RX errors?

[ath9k-devel] AR9280 - OFDM RX errors?

[Adrian Chadd]

Hi,

I'm debugging Linux ath9k (a tplink 1043ND) -> FreeBSD AR9280 station
in 11n mode. The problem is RX'ing packets on the FreeBSD station.

The throughput problems I'm having can be traced down (so far) to
-lots- of CCK/OFDM decoding errors. I get CRC errors and when I turned
on all the phy error mask bits, I also get various OFDM and CCK
decoding errors, with error 17 (OFDM timing) topping the lot.

Enabling ANI doesn't have an effect - I watched the ANI code slowly
write higher immunity values to the hardware, and then disable OFDM
weak detection. It had no effect.

I've just gone and synced the FreeBSD board setup code with the board
defaults code in ath9k. It didn't have any measurable effect on the
OFDM side of things.

Does anyone have any suggestions where I could continue digging here?
I'm sure Linux would work fine on this card ( :-)

Thanks,


Adrian

[ath9k-devel] AR9280 - OFDM RX errors?

[Brian Prodoehl]

On Mon, Feb 7, 2011 at 5:10 PM, Adrian Chadd <adrian.chadd@gmail.com> wrote:
> Hi,
>
> I'm debugging Linux ath9k (a tplink 1043ND) -> FreeBSD AR9280 station
> in 11n mode. The problem is RX'ing packets on the FreeBSD station.
>
> The throughput problems I'm having can be traced down (so far) to
> -lots- of CCK/OFDM decoding errors. I get CRC errors and when I turned
> on all the phy error mask bits, I also get various OFDM and CCK
> decoding errors, with error 17 (OFDM timing) topping the lot.
>
> Enabling ANI doesn't have an effect - I watched the ANI code slowly
> write higher immunity values to the hardware, and then disable OFDM
> weak detection. It had no effect.
>
> I've just gone and synced the FreeBSD board setup code with the board
> defaults code in ath9k. It didn't have any measurable effect on the
> OFDM side of things.
>
> Does anyone have any suggestions where I could continue digging here?
> I'm sure Linux would work fine on this card ( :-)
>
> Thanks,
>
>
> Adrian

You may want to look into adding some rough ANI, following the "new"
ANI routines in ath9k.  Normally when the OFDM or CCK error rate rises
above a certain level (maybe 200 errors/second), the driver will bump
up a few interference mitigation parameters.  Are you successfully
performing noise floor calibration?  I'm not sure on the OFDM timing
error, in particular, so maybe someone can shed some light on that
one.

-Brian

[ath9k-devel] AR9280 - OFDM RX errors?

[Adrian Chadd]

On 8 February 2011 10:51, Brian Prodoehl <bprodoehl@gmail.com> wrote:

> You may want to look into adding some rough ANI, following the "new"
> ANI routines in ath9k. ?Normally when the OFDM or CCK error rate rises
> above a certain level (maybe 200 errors/second), the driver will bump
> up a few interference mitigation parameters. ?Are you successfully
> performing noise floor calibration? ?I'm not sure on the OFDM timing
> error, in particular, so maybe someone can shed some light on that
> one.

I'll take another look at the "new" ANI routines and see how they
differ from the old ones. (I guess I should also re-read the patent
doc which covers the old ANI implementation.)

Ok, I've just re-read the patent and I'm looking at the "new" ANI
code. The new ANI code seems to be a lot like the old ANI code,
except:

* it doesn't use hard-coded ANI tables;
* ANI operations become "optional" in some cases;
* it caches some of the register values (AR_PHY_SFCORR,
AR_PHY_SFCORR_LOW, AR_PHY_SFCORR_EXT, AR_PHY_FIND_SIG,
AR_PHY_FIND_SIG_LOW, AR_PHY_TIMING5, AR_PHY_EXT_CCA) at startup;
* It modifies (some) of the ANI parameters relative to the cached
register values, rather than writing absolute values to the hardware.

Does this about summarise it?



Adrian

[ath9k-devel] AR9280 - OFDM RX errors?

[Luis R. Rodriguez]

On Mon, Feb 07, 2011 at 11:56:02PM -0800, Adrian Chadd wrote:
> On 8 February 2011 10:51, Brian Prodoehl <bprodoehl@gmail.com> wrote:
> 
> > You may want to look into adding some rough ANI, following the "new"
> > ANI routines in ath9k. ?Normally when the OFDM or CCK error rate rises
> > above a certain level (maybe 200 errors/second), the driver will bump
> > up a few interference mitigation parameters. ?Are you successfully
> > performing noise floor calibration? ?I'm not sure on the OFDM timing
> > error, in particular, so maybe someone can shed some light on that
> > one.
> 
> I'll take another look at the "new" ANI routines and see how they
> differ from the old ones. (I guess I should also re-read the patent
> doc which covers the old ANI implementation.)
> 
> Ok, I've just re-read the patent and I'm looking at the "new" ANI
> code. The new ANI code seems to be a lot like the old ANI code,
> except:
> 
> * it doesn't use hard-coded ANI tables;
> * ANI operations become "optional" in some cases;
> * it caches some of the register values (AR_PHY_SFCORR,
> AR_PHY_SFCORR_LOW, AR_PHY_SFCORR_EXT, AR_PHY_FIND_SIG,
> AR_PHY_FIND_SIG_LOW, AR_PHY_TIMING5, AR_PHY_EXT_CCA) at startup;
> * It modifies (some) of the ANI parameters relative to the cached
> register values, rather than writing absolute values to the hardware.
> 
> Does this about summarise it?

git log is a treasure chest:

commit e36b27aff1b10c81c53990b28da4ab6ab0ed0761
Author: Luis R. Rodriguez <lrodriguez@atheros.com>
Date:   Sat Jun 12 00:33:45 2010 -0400

    ath9k: add new ANI implementation for AR9003
    
    This adds support for ANI for AR9003. The implementation for
    ANI for AR9003 is slightly different than the one used for
    the older chipset families. It can technically be used for
    the older families as well but this is not yet fully tested
    so we only enable the new ANI for the AR5008, AR9001 and AR9002
    families with a module parameter, force_new_ani.
    
    The old ANI implementation is left intact.
    
    Details of the new ANI implemention:
    
      * ANI adjustment logic is now table driven so that each ANI level
        setting is parameterized. This makes adjustments much more
        deterministic than the old procedure based logic and allows
        adjustments to be made incrementally to several parameters per
        level.
    
      * ANI register settings are now relative to INI values; so ANI
        param zero level == INI value. Appropriate floor and ceiling
        values are obeyed when adjustments are combined with INI values.

      * ANI processing is done once per second rather that every 100ms.
        The poll interval is now a set upon hardware initialization and
        can be picked up by the core driver.
    
      * OFDM error and CCK error processing are made in a round robin
        fashion rather than allowing all OFDM adjustments to be made
        before CCK adjustments.
    
      * ANI adjusts MRC CCK off in the presence of high CCK errors
    
      * When adjusting spur immunity (SI) and OFDM weak signal detection,
        ANI now sets register values for the extension channel too
    
      * When adjusting FIR step (ST), ANI now sets register for FIR step
        low too
    
      * FIR step adjustments now allow for an extra level of immunity for
        extremely noisy environments
    
      * The old Noise immunity setting (NI), which changes coarse low, size
        desired, etc have been removed. Changing these settings could affect
        up RIFS RX as well.
    
      * CCK weak signal adjustment is no longer used
    
      * ANI no longer enables phy error interrupts; in all cases phy hw
        counting registers are used instead
    
      * The phy error count (overflow) interrupts are also no longer used
        for ANI adjustments. All ANI adjustments are made via the polling
        routine and no adjustments are possible in the ISR context anymore
    
      * A history settings buffer is now correctly used for each channel;
        channel settings are initialized with the defaults but later
        changes are restored when returning back to that channel
    
      * When scanning, ANI is disabled settings are returned to (INI) defaults.
    
      * OFDM phy error thresholds are now 400 & 1000 (errors/second units) for
        low/high water marks, providing increased stability/hysteresis when
        changing levels.

      * Similarly CCK phy error thresholds are now 300 & 600 (errors/second)
    
    Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

I'll also say that our goal is to eventually get ANI v2 tested with non-AR9003
cards but due to lack of time we have not been able to do full system testing
on it, users however can test it by using the module parameter force_new_ani=1
on the ath9k_hw module.

  Luis

[ath9k-devel] AR9280 - OFDM RX errors?

[Adrian Chadd]

Yup, I found that, and figured it out from the code.

Knowing about what broke RIFS RX is helpful to know.

I may just port this for the AR9160/AR9280; it makes me happy that the
MIB interrupt stuff was removed here for these later cards (I'd begun
doing much the same in FreeBSD for the AR5416 and later.)

So right now I'm seeing:

FreeBSD STA (ar9280) -> ath9k hostap (AR913x) - can TX at MCS12
reliably; anything greater results in large amounts of packet loss
ath9k hostap -> FreeBSD STA - can TX at MCS7 reliably; anything
greater results in large amounts of packet loss.

I've verified that I'm enabling TX/RX chainmasks "right". What else
would affect MCS8-15 RX on the AR9280? What else would be worth
tracking? I'm going to begin tracking per-chain RX RSSI just to see if
something strange shows up there; any other suggestions?


Adrian

On 9 February 2011 02:22, Luis R. Rodriguez <lrodriguez@atheros.com> wrote:
> On Mon, Feb 07, 2011 at 11:56:02PM -0800, Adrian Chadd wrote:
>> On 8 February 2011 10:51, Brian Prodoehl <bprodoehl@gmail.com> wrote:
>>
>> > You may want to look into adding some rough ANI, following the "new"
>> > ANI routines in ath9k. ?Normally when the OFDM or CCK error rate rises
>> > above a certain level (maybe 200 errors/second), the driver will bump
>> > up a few interference mitigation parameters. ?Are you successfully
>> > performing noise floor calibration? ?I'm not sure on the OFDM timing
>> > error, in particular, so maybe someone can shed some light on that
>> > one.
>>
>> I'll take another look at the "new" ANI routines and see how they
>> differ from the old ones. (I guess I should also re-read the patent
>> doc which covers the old ANI implementation.)
>>
>> Ok, I've just re-read the patent and I'm looking at the "new" ANI
>> code. The new ANI code seems to be a lot like the old ANI code,
>> except:
>>
>> * it doesn't use hard-coded ANI tables;
>> * ANI operations become "optional" in some cases;
>> * it caches some of the register values (AR_PHY_SFCORR,
>> AR_PHY_SFCORR_LOW, AR_PHY_SFCORR_EXT, AR_PHY_FIND_SIG,
>> AR_PHY_FIND_SIG_LOW, AR_PHY_TIMING5, AR_PHY_EXT_CCA) at startup;
>> * It modifies (some) of the ANI parameters relative to the cached
>> register values, rather than writing absolute values to the hardware.
>>
>> Does this about summarise it?
>
> git log is a treasure chest:
>
> commit e36b27aff1b10c81c53990b28da4ab6ab0ed0761
> Author: Luis R. Rodriguez <lrodriguez@atheros.com>
> Date: ? Sat Jun 12 00:33:45 2010 -0400
>
> ? ?ath9k: add new ANI implementation for AR9003
>
> ? ?This adds support for ANI for AR9003. The implementation for
> ? ?ANI for AR9003 is slightly different than the one used for
> ? ?the older chipset families. It can technically be used for
> ? ?the older families as well but this is not yet fully tested
> ? ?so we only enable the new ANI for the AR5008, AR9001 and AR9002
> ? ?families with a module parameter, force_new_ani.
>
> ? ?The old ANI implementation is left intact.
>
> ? ?Details of the new ANI implemention:
>
> ? ? ?* ANI adjustment logic is now table driven so that each ANI level
> ? ? ? ?setting is parameterized. This makes adjustments much more
> ? ? ? ?deterministic than the old procedure based logic and allows
> ? ? ? ?adjustments to be made incrementally to several parameters per
> ? ? ? ?level.
>
> ? ? ?* ANI register settings are now relative to INI values; so ANI
> ? ? ? ?param zero level == INI value. Appropriate floor and ceiling
> ? ? ? ?values are obeyed when adjustments are combined with INI values.
>
> ? ? ?* ANI processing is done once per second rather that every 100ms.
> ? ? ? ?The poll interval is now a set upon hardware initialization and
> ? ? ? ?can be picked up by the core driver.
>
> ? ? ?* OFDM error and CCK error processing are made in a round robin
> ? ? ? ?fashion rather than allowing all OFDM adjustments to be made
> ? ? ? ?before CCK adjustments.
>
> ? ? ?* ANI adjusts MRC CCK off in the presence of high CCK errors
>
> ? ? ?* When adjusting spur immunity (SI) and OFDM weak signal detection,
> ? ? ? ?ANI now sets register values for the extension channel too
>
> ? ? ?* When adjusting FIR step (ST), ANI now sets register for FIR step
> ? ? ? ?low too
>
> ? ? ?* FIR step adjustments now allow for an extra level of immunity for
> ? ? ? ?extremely noisy environments
>
> ? ? ?* The old Noise immunity setting (NI), which changes coarse low, size
> ? ? ? ?desired, etc have been removed. Changing these settings could affect
> ? ? ? ?up RIFS RX as well.
>
> ? ? ?* CCK weak signal adjustment is no longer used
>
> ? ? ?* ANI no longer enables phy error interrupts; in all cases phy hw
> ? ? ? ?counting registers are used instead
>
> ? ? ?* The phy error count (overflow) interrupts are also no longer used
> ? ? ? ?for ANI adjustments. All ANI adjustments are made via the polling
> ? ? ? ?routine and no adjustments are possible in the ISR context anymore
>
> ? ? ?* A history settings buffer is now correctly used for each channel;
> ? ? ? ?channel settings are initialized with the defaults but later
> ? ? ? ?changes are restored when returning back to that channel
>
> ? ? ?* When scanning, ANI is disabled settings are returned to (INI) defaults.
>
> ? ? ?* OFDM phy error thresholds are now 400 & 1000 (errors/second units) for
> ? ? ? ?low/high water marks, providing increased stability/hysteresis when
> ? ? ? ?changing levels.
>
> ? ? ?* Similarly CCK phy error thresholds are now 300 & 600 (errors/second)
>
> ? ?Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ? ?Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> I'll also say that our goal is to eventually get ANI v2 tested with non-AR9003
> cards but due to lack of time we have not been able to do full system testing
> on it, users however can test it by using the module parameter force_new_ani=1
> on the ath9k_hw module.
>
> ?Luis
>

[ath9k-devel] AR9280 - OFDM RX errors?

[Adrian Chadd]

Hi all again,

Manually writing register values to disable OFDM weak signal detection
fixes the OFDM timing errors and the PHY error rates disappear to
almost 0.

But there's still a high level of CRC errors and ath9k is doing a
-lot- of retries, whether TX'ing A-MPDU to me or not.

The question is - what next?

I'll go off and put a station into 11n monitor mode an see if that
station sees the CRC errors or not.



Adrian

[ath9k-devel] AR9280 - OFDM RX errors?

[Adrian Chadd]

On 8 February 2011 06:10, Adrian Chadd <adrian.chadd@gmail.com> wrote:

> The throughput problems I'm having can be traced down (so far) to
> -lots- of CCK/OFDM decoding errors. I get CRC errors and when I turned
> on all the phy error mask bits, I also get various OFDM and CCK
> decoding errors, with error 17 (OFDM timing) topping the lot.

As a followup, I've just disabled ANI entirely and manually written in
values to the sfcorr/sfcorr_low registers to disable OFDM weak
detection. This significantly reduces the number of CRC/OFDM timing
PHY errors when no traffic is going on, but there are still
significant OFDM timing/CRC errors when RX'ing.

What else should I look at?



Adrian

[ath9k-devel] AR9280 - OFDM RX errors?

[Deep Shah]

Adrian Chadd <adrian.chadd <at> gmail.com> writes:

> 
> On 8 February 2011 06:10, Adrian Chadd <adrian.chadd <at> gmail.com> wrote:
> 
> > The throughput problems I'm having can be traced down (so far) to
> > -lots- of CCK/OFDM decoding errors. I get CRC errors and when I turned
> > on all the phy error mask bits, I also get various OFDM and CCK
> > decoding errors, with error 17 (OFDM timing) topping the lot.
> 
> As a followup, I've just disabled ANI entirely and manually written in
> values to the sfcorr/sfcorr_low registers to disable OFDM weak
> detection. This significantly reduces the number of CRC/OFDM timing
> PHY errors when no traffic is going on, but there are still
> significant OFDM timing/CRC errors when RX'ing.
> 
> What else should I look at?
> 
> Adrian
> 

Hi All,

I think you all have debugged this issue in depth and will be very much thankful
if you can help me out in one similar issue which I am facing currently. Thank
you very much in advance. 

I am facing very similar issue with throughput. I am using 9390 as my chipset
and I am using madwifi driver for the same. With this configurations of hardware
and software, I am running my own application for creating 11n point to point
network. 

In this case, I am facing issues with throughput. When I increase distance. my
throughput becomes very low in case of 11n, while in case of legacy mode, I am
facing less issues in throughput. I tries to print some counter values for OFDM
phy erros and CCK phy erros, which increasing drastically while running
throughput test. 

Can you please give me some information about what can be done to resolve this? 

Your support will be really helpful for me to debug and resolve this issue. 

Thanks,
Deep

[ath9k-devel] AR9280 - OFDM RX errors?

[Adrian Chadd]

Hi,

There's no AR9390 support in the madwifi codebase. Which driver
codebase are you using?



adrian


On 20 September 2012 05:55, Deep Shah <deep.shah@strixsystems.com> wrote:
> Adrian Chadd <adrian.chadd <at> gmail.com> writes:
>
>>
>> On 8 February 2011 06:10, Adrian Chadd <adrian.chadd <at> gmail.com> wrote:
>>
>> > The throughput problems I'm having can be traced down (so far) to
>> > -lots- of CCK/OFDM decoding errors. I get CRC errors and when I turned
>> > on all the phy error mask bits, I also get various OFDM and CCK
>> > decoding errors, with error 17 (OFDM timing) topping the lot.
>>
>> As a followup, I've just disabled ANI entirely and manually written in
>> values to the sfcorr/sfcorr_low registers to disable OFDM weak
>> detection. This significantly reduces the number of CRC/OFDM timing
>> PHY errors when no traffic is going on, but there are still
>> significant OFDM timing/CRC errors when RX'ing.
>>
>> What else should I look at?
>>
>> Adrian
>>
>
> Hi All,
>
> I think you all have debugged this issue in depth and will be very much thankful
> if you can help me out in one similar issue which I am facing currently. Thank
> you very much in advance.
>
> I am facing very similar issue with throughput. I am using 9390 as my chipset
> and I am using madwifi driver for the same. With this configurations of hardware
> and software, I am running my own application for creating 11n point to point
> network.
>
> In this case, I am facing issues with throughput. When I increase distance. my
> throughput becomes very low in case of 11n, while in case of legacy mode, I am
> facing less issues in throughput. I tries to print some counter values for OFDM
> phy erros and CCK phy erros, which increasing drastically while running
> throughput test.
>
> Can you please give me some information about what can be done to resolve this?
>
> Your support will be really helpful for me to debug and resolve this issue.
>
> Thanks,
> Deep
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] AR9280 - OFDM RX errors?

[Deep Shah]

Hi Adrian,

Thank you very much for your reply.

Madwifi versions (madwifi-9.1.0.309 and madwifi-9.2.0.309) has support of
AR9300 in which the support is available for ar9390 chipset. I am
using madwifi-9.1.0.309
for my codebase.

Regards,
Deep



On Fri, Sep 21, 2012 at 3:03 AM, Adrian Chadd <adrian@freebsd.org> wrote:

> Hi,
>
> There's no AR9390 support in the madwifi codebase. Which driver
> codebase are you using?
>
>
>
> adrian
>
>
> On 20 September 2012 05:55, Deep Shah <deep.shah@strixsystems.com> wrote:
> > Adrian Chadd <adrian.chadd <at> gmail.com> writes:
> >
> >>
> >> On 8 February 2011 06:10, Adrian Chadd <adrian.chadd <at> gmail.com>
> wrote:
> >>
> >> > The throughput problems I'm having can be traced down (so far) to
> >> > -lots- of CCK/OFDM decoding errors. I get CRC errors and when I turned
> >> > on all the phy error mask bits, I also get various OFDM and CCK
> >> > decoding errors, with error 17 (OFDM timing) topping the lot.
> >>
> >> As a followup, I've just disabled ANI entirely and manually written in
> >> values to the sfcorr/sfcorr_low registers to disable OFDM weak
> >> detection. This significantly reduces the number of CRC/OFDM timing
> >> PHY errors when no traffic is going on, but there are still
> >> significant OFDM timing/CRC errors when RX'ing.
> >>
> >> What else should I look at?
> >>
> >> Adrian
> >>
> >
> > Hi All,
> >
> > I think you all have debugged this issue in depth and will be very much
> thankful
> > if you can help me out in one similar issue which I am facing currently.
> Thank
> > you very much in advance.
> >
> > I am facing very similar issue with throughput. I am using 9390 as my
> chipset
> > and I am using madwifi driver for the same. With this configurations of
> hardware
> > and software, I am running my own application for creating 11n point to
> point
> > network.
> >
> > In this case, I am facing issues with throughput. When I increase
> distance. my
> > throughput becomes very low in case of 11n, while in case of legacy
> mode, I am
> > facing less issues in throughput. I tries to print some counter values
> for OFDM
> > phy erros and CCK phy erros, which increasing drastically while running
> > throughput test.
> >
> > Can you please give me some information about what can be done to
> resolve this?
> >
> > Your support will be really helpful for me to debug and resolve this
> issue.
> >
> > Thanks,
> > Deep
> >
> >
> > _______________________________________________
> > ath9k-devel mailing list
> > ath9k-devel at lists.ath9k.org
> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20120921/67a6bf41/attachment.htm 

[ath9k-devel] AR9280 - OFDM RX errors?

[Deep Shah]

Deep Shah <deep.shah <at> strixsystems.com> writes:

> 
> Hi Adrian,Thank you very much for your reply. Madwifi versions
(madwifi-9.1.0.309 and madwifi-9.2.0.309) has support of
>  AR9300 in which the support is available for ar9390 chipset. I am using
madwifi-9.1.0.309  for my codebase. Regards,DeepOn Fri, Sep 21, 2012 at 3:03 AM,
Adrian Chadd <adrian <at> freebsd.org> wrote:
> 
> Hi,
> There's no AR9390 support in the madwifi codebase. Which driver
> codebase are you using?
> adrian
> On 20 September 2012 05:55, Deep Shah <deep.shah <at> strixsystems.com> wrote:
> > Adrian Chadd <adrian.chadd <at> gmail.com> writes:
> >
> >>
> >> On 8 February 2011 06:10, Adrian Chadd <adrian.chadd <at> gmail.com> wrote:
> >>
> >> > The throughput problems I'm having can be traced down (so far) to
> >> > -lots- of CCK/OFDM decoding errors. I get CRC errors and when I turned
> >> > on all the phy error mask bits, I also get various OFDM and CCK
> >> > decoding errors, with error 17 (OFDM timing) topping the lot.
> >>
> >> As a followup, I've just disabled ANI entirely and manually written in
> >> values to the sfcorr/sfcorr_low registers to disable OFDM weak
> >> detection. This significantly reduces the number of CRC/OFDM timing
> >> PHY errors when no traffic is going on, but there are still
> >> significant OFDM timing/CRC errors when RX'ing.
> >>
> >> What else should I look at?
> >>
> >> Adrian
> >>
> >


Hi,

The same was provided with the SDK of board which I am working on.

Also I want to understand that, 
any other functional change or some feature change (enable/disable) 
will be helpful in long distance link for better throughput?

Regards,
Deep

[ath9k-devel] AR9280 - OFDM RX errors?

[Deep Shah]

Adrian Chadd <adrian <at> freebsd.org> writes:

> 
> Hi,
> 
> There's no AR9390 support in the madwifi codebase. Which driver
> codebase are you using?
> 
> adrian
> 
> On 20 September 2012 05:55, Deep Shah <deep.shah <at> strixsystems.com> wrote:
> > Adrian Chadd <adrian.chadd <at> gmail.com> writes:


Hi Adrian,

Thank you very much for your reply.

Madwifi versions (madwifi-9.1.0.309 and madwifi-9.2.0.309) has support of AR9300.
In which the support is available for ar9390 chipset. 

I am using madwifi-9.1.0.309 for my codebase.

Regards,
Deep

[ath9k-devel] AR9280 - OFDM RX errors?

[Adrian Chadd]

Hi,

Where'd you download this version of madwifi from?



Adrian


On 21 September 2012 04:33, Deep Shah <deep.shah@strixsystems.com> wrote:
> Adrian Chadd <adrian <at> freebsd.org> writes:
>
>>
>> Hi,
>>
>> There's no AR9390 support in the madwifi codebase. Which driver
>> codebase are you using?
>>
>> adrian
>>
>> On 20 September 2012 05:55, Deep Shah <deep.shah <at> strixsystems.com> wrote:
>> > Adrian Chadd <adrian.chadd <at> gmail.com> writes:
>
>
> Hi Adrian,
>
> Thank you very much for your reply.
>
> Madwifi versions (madwifi-9.1.0.309 and madwifi-9.2.0.309) has support of AR9300.
> In which the support is available for ar9390 chipset.
>
> I am using madwifi-9.1.0.309 for my codebase.
>
> Regards,
> Deep
>
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] AR9280 - OFDM RX errors?

[Deep Shah]

Hi,

The same was provided with the SDK of board which I am working on.

Also I want to understand that, any other functional change or some feature
change (enable/disable) will be helpful in long distance link for better
throughput?

Regards,
Deep



On Sat, Sep 22, 2012 at 2:00 PM, Adrian Chadd <adrian@freebsd.org> wrote:

> Hi,
>
> Where'd you download this version of madwifi from?
>
>
>
> Adrian
>
>
> On 21 September 2012 04:33, Deep Shah <deep.shah@strixsystems.com> wrote:
> > Adrian Chadd <adrian <at> freebsd.org> writes:
> >
> >>
> >> Hi,
> >>
> >> There's no AR9390 support in the madwifi codebase. Which driver
> >> codebase are you using?
> >>
> >> adrian
> >>
> >> On 20 September 2012 05:55, Deep Shah <deep.shah <at> strixsystems.com>
> wrote:
> >> > Adrian Chadd <adrian.chadd <at> gmail.com> writes:
> >
> >
> > Hi Adrian,
> >
> > Thank you very much for your reply.
> >
> > Madwifi versions (madwifi-9.1.0.309 and madwifi-9.2.0.309) has support
> of AR9300.
> > In which the support is available for ar9390 chipset.
> >
> > I am using madwifi-9.1.0.309 for my codebase.
> >
> > Regards,
> > Deep
> >
> >
> >
> > _______________________________________________
> > ath9k-devel mailing list
> > ath9k-devel at lists.ath9k.org
> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20120924/7597a1fa/attachment.htm 

[ath9k-devel] AR9280 - OFDM RX errors?

[Deep Shah]

Hi,

Also I want to add that, disabling ANI on station side is helping me in
throughput for some amount but not more.

Regards,
Deep

On Monday, September 24, 2012, Deep Shah <deep.shah@strixsystems.com> wrote:
> Hi,
>
> The same was provided with the SDK of board which I am working on.
>
> Also I want to understand that, any other functional change or some
feature change (enable/disable) will be helpful in long distance link for
better throughput?
>
> Regards,
> Deep
>
>
>
> On Sat, Sep 22, 2012 at 2:00 PM, Adrian Chadd <adrian@freebsd.org> wrote:
>>
>> Hi,
>>
>> Where'd you download this version of madwifi from?
>>
>>
>>
>> Adrian
>>
>>
>> On 21 September 2012 04:33, Deep Shah <deep.shah@strixsystems.com> wrote:
>> > Adrian Chadd <adrian <at> freebsd.org> writes:
>> >
>> >>
>> >> Hi,
>> >>
>> >> There's no AR9390 support in the madwifi codebase. Which driver
>> >> codebase are you using?
>> >>
>> >> adrian
>> >>
>> >> On 20 September 2012 05:55, Deep Shah <deep.shah <at> strixsystems.com>
wrote:
>> >> > Adrian Chadd <adrian.chadd <at> gmail.com> writes:
>> >
>> >
>> > Hi Adrian,
>> >
>> > Thank you very much for your reply.
>> >
>> > Madwifi versions (madwifi-9.1.0.309 and madwifi-9.2.0.309) has support
of AR9300.
>> > In which the support is available for ar9390 chipset.
>> >
>> > I am using madwifi-9.1.0.309 for my codebase.
>> >
>> > Regards,
>> > Deep
>> >
>> >
>> >
>> > _______________________________________________
>> > ath9k-devel mailing list
>> > ath9k-devel at lists.ath9k.org
>> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>

-- 
Regards,
Deep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20120924/94d5decb/attachment.htm 

[ath9k-devel] AR9280 - OFDM RX errors?

[Adrian Chadd]

On 24 September 2012 05:16, Deep Shah <deep.shah@strixsystems.com> wrote:
> Hi,
>
> The same was provided with the SDK of board which I am working on.
>
> Also I want to understand that, any other functional change or some feature
> change (enable/disable) will be helpful in long distance link for better
> throughput?

Hi,

Right. So it's not a public release. It's either based on the Qualcomm
Atheros 9.x release (or is the QCA 9.x carrier release, I'd have to
check) or something some third party has done.

You're going to have to ask QCA for support on this one. :-)

As for long distance links - the things to look at are the ACK,
RTS/CTS timeouts and slot time settings.



Adrian