[ath9k-devel] QCA9558 problems for MCS 14/15

[ath9k-devel] QCA9558 problems for MCS 14/15

[Simon Wunderlich]

Hello ath9k-devs,

we have an issue with a new QCA9558 SoC based board (Rev 0, a 3x3 2.4G board). 
We were doing performance tests with various 2-stream 802.11n clients, but 
appearently the high MCS rates 14 and 15 can not be used reliably with ath9k - 
rc_stats show that transmission fail most of the time, and the connected 
clients don't receive them as well. The original firmware with an Atheros 9.5 
driver (9.5.3.15) does not show that behaviour and works fine. Therefore we 
assume that there is something missing/wrong in ath9k. Iperf tests in HT20 
showed 60 Mbit/s with ath9k and 80 Mbit/s with the original firmware (distance 
1-3 meter).

We have been in contact with Sujith who kindly helped us and checked for 
updates, thanks to his work some patches made it to the mailing list. However 
the problem is not yet solved on our AP, and while we are still working on it, 
I'd like to get your opinions as well.

What we did so far: We have tested Intel and Atheros clients (2-stream) which 
work fine with other Access Points. We have tested various driver versions 
(OpenWRT trunk, OpenWRT with manually backported drivers from latest wireless-
testing, including Sujiths latest patches). We have also tried different 
hardware samples. We experience the described problem in all of these 
combinations, ath9k/minstrel tops out at MCS12/13 maximum (manual setting 
MCS15 fails as well).

Any ideas and suggestions (also how to debug the problem further) would be 
very much appreciated.

Thank you,
   Simon

[ath9k-devel] QCA9558 problems for MCS 14/15

[Thomas Hühn]

Hi Simon,

You said that even manually setting MC14 or MC15 as static rate fails. So seems that it is not an issue at the mac layer rather than the phy layer.
I had once something similar on ath5k, where the power curves got not properly assigned to high rates.
 So just in case, could you check if those two high rates do work if you lower the global transmit power to 12 dBm ?

Bye Bluse

On 22.11.2013, at 16:57, Simon Wunderlich <simon@open-mesh.com> wrote:

> Hello ath9k-devs,
> 
> we have an issue with a new QCA9558 SoC based board (Rev 0, a 3x3 2.4G board). 
> We were doing performance tests with various 2-stream 802.11n clients, but 
> appearently the high MCS rates 14 and 15 can not be used reliably with ath9k - 
> rc_stats show that transmission fail most of the time, and the connected 
> clients don't receive them as well. The original firmware with an Atheros 9.5 
> driver (9.5.3.15) does not show that behaviour and works fine. Therefore we 
> assume that there is something missing/wrong in ath9k. Iperf tests in HT20 
> showed 60 Mbit/s with ath9k and 80 Mbit/s with the original firmware (distance 
> 1-3 meter).
> 
> We have been in contact with Sujith who kindly helped us and checked for 
> updates, thanks to his work some patches made it to the mailing list. However 
> the problem is not yet solved on our AP, and while we are still working on it, 
> I'd like to get your opinions as well.
> 
> What we did so far: We have tested Intel and Atheros clients (2-stream) which 
> work fine with other Access Points. We have tested various driver versions 
> (OpenWRT trunk, OpenWRT with manually backported drivers from latest wireless-
> testing, including Sujiths latest patches). We have also tried different 
> hardware samples. We experience the described problem in all of these 
> combinations, ath9k/minstrel tops out at MCS12/13 maximum (manual setting 
> MCS15 fails as well).
> 
> Any ideas and suggestions (also how to debug the problem further) would be 
> very much appreciated.
> 
> Thank you,
>   Simon
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] QCA9558 problems for MCS 14/15

[Sven Eckelmann]

On Saturday 23 November 2013 10:37:46 Thomas H?hn wrote:
> You said that even manually setting MC14 or MC15 as static rate fails. So
> seems that it is not an issue at the mac layer rather than the phy layer. I
> had once something similar on ath5k, where the power curves got not
> properly assigned to high rates. So just in case, could you check if those
> two high rates do work if you lower the global transmit power to 12 dBm ?

Thanks for the input. This was tested quite early in the process with 
5/10/15/20 dBm and didn't seem to affect the throughput in a positive way.

Kind regards,
	Sven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20131125/3e1e31c1/attachment.pgp 

[ath9k-devel] QCA9558 problems for MCS 14/15

[Simon Wunderlich]

> On Saturday 23 November 2013 10:37:46 Thomas H?hn wrote:
> > You said that even manually setting MC14 or MC15 as static rate fails. So
> > seems that it is not an issue at the mac layer rather than the phy layer.
> > I had once something similar on ath5k, where the power curves got not
> > properly assigned to high rates. So just in case, could you check if
> > those two high rates do work if you lower the global transmit power to
> > 12 dBm ?
> 
> Thanks for the input. This was tested quite early in the process with
> 5/10/15/20 dBm and didn't seem to affect the throughput in a positive way.

Anyone any other ideas? :)

Today we've tried another round of the latest OpenWRT + pending patches from 
the ath9k mailing list, but still no change. We'd appreciate your ideas a lot. 
:)

Thanks,
    Simon

[ath9k-devel] QCA9558 problems for MCS 14/15

[Adrian Chadd]

On 29 November 2013 09:59, Simon Wunderlich <sw@simonwunderlich.de> wrote:

> Anyone any other ideas? :)
>
> Today we've tried another round of the latest OpenWRT + pending patches from
> the ath9k mailing list, but still no change. We'd appreciate your ideas a lot.
> :)

9.5.3.15 works fine, right? Do you have the source for it?

I'll go hit up QCA people (under NDA, of course! :) to see if I can
get this particular LSDK version and see what particular hacks are in
for this driver version.



-a

[ath9k-devel] QCA9558 problems for MCS 14/15

[Simon Wunderlich]

Hey Adrian,

> On 29 November 2013 09:59, Simon Wunderlich <sw@simonwunderlich.de> wrote:
> > Anyone any other ideas? :)
> > 
> > Today we've tried another round of the latest OpenWRT + pending patches
> > from the ath9k mailing list, but still no change. We'd appreciate your
> > ideas a lot.
> > 
> > :)
> 
> 9.5.3.15 works fine, right? Do you have the source for it?

Yes, it works fine, or at least much better than ath9k in its current state. We 
don't have the source for Atheros drivers, it was part of the original firmware 
which was installed on these devices. We have asked if the vendor modified 
anything to "tune" for these particular devices, and that would be: disabled 
RTS/CTS, increased beacon interval, disabled beamforming. This didn't give us 
any clue why we have problems in ath9k, though ....
> 
> I'll go hit up QCA people (under NDA, of course! :) to see if I can
> get this particular LSDK version and see what particular hacks are in
> for this driver version.

Thanks a lot for your help! :D

Cheers,
    Simon

[ath9k-devel] QCA9558 problems for MCS 14/15

[Adrian Chadd]

Well, did you try disabling RTS/CTS and increase the beacon interval?

TxBF isn't implemented in ath9k, so it's fine.

Who is the vendor?



-adrian


On 30 November 2013 08:22, Simon Wunderlich <sw@simonwunderlich.de> wrote:
> Hey Adrian,
>
>> On 29 November 2013 09:59, Simon Wunderlich <sw@simonwunderlich.de> wrote:
>> > Anyone any other ideas? :)
>> >
>> > Today we've tried another round of the latest OpenWRT + pending patches
>> > from the ath9k mailing list, but still no change. We'd appreciate your
>> > ideas a lot.
>> >
>> > :)
>>
>> 9.5.3.15 works fine, right? Do you have the source for it?
>
> Yes, it works fine, or at least much better than ath9k in its current state. We
> don't have the source for Atheros drivers, it was part of the original firmware
> which was installed on these devices. We have asked if the vendor modified
> anything to "tune" for these particular devices, and that would be: disabled
> RTS/CTS, increased beacon interval, disabled beamforming. This didn't give us
> any clue why we have problems in ath9k, though ....
>>
>> I'll go hit up QCA people (under NDA, of course! :) to see if I can
>> get this particular LSDK version and see what particular hacks are in
>> for this driver version.
>
> Thanks a lot for your help! :D
>
> Cheers,
>     Simon

[ath9k-devel] QCA9558 problems for MCS 14/15

[Simon Wunderlich]

> Well, did you try disabling RTS/CTS and increase the beacon interval?

Yep, we tried both but that didn't make any difference.
> 
> TxBF isn't implemented in ath9k, so it's fine.

Yup, we didn't find that in the driver, so it's good that you confirm that. ;)

I guess these "tunings" were not adressing our problems, but the problem 
wasn't present in the proprietary driver to begin with.

Thanks,
   Simon