[ath9k-devel] ath9k_htc over 20 Nodes

[ath9k-devel] ath9k_htc over 20 Nodes

[Lukas Göstl]

Hi again,

I got my Mesh Network running without any of the wireless adapters getting stuck. The Problem was that the adapter got overwhelmed 
when the ath9k driver wanted to send more packets than the adapter could process. More precisely the adapter got Problems when
the HTC_MAX_TX_STATUS (defined as 12) was reached. So I reduced the software queue of the ath9k driver from 256 to 12 Packets. 

However the performance could be better. Has anyone an idea for another solution or a suggestion to increase the performance?

Thanks,
Lukas

> Hi all,
> 
> i successfully build up a secure Mesh Network over 20 Nodes with wpa_supplicant, ath9k_htc and linux-kernel 3.18
> 
> I know there is a limit of station peering's on ath9k_htc, however I whitelisted the stations in a way, that only 7 Peers authenticate with each other.
>
> The Mesh Network runs well for about 2 - 3 hours. Then some wireless adapters get stuck and do not response anymore. They need a Powercycle to work again.
> 
> Has anybody an idea why this happens or what`s the best way to debug such a problem? I don't get any output in syslog.
> 
> Thanks,
> Lukas

[ath9k-devel] ath9k_htc over 20 Nodes

[Oleksij Rempel]

Hi,

thank you for your testing.

Am 23.12.2015 um 11:53 schrieb Lukas G?stl:
> Hi again,
> 
> I got my Mesh Network running without any of the wireless adapters getting stuck. The Problem was that the adapter got overwhelmed 
> when the ath9k driver wanted to send more packets than the adapter could process. More precisely the adapter got Problems when
> the HTC_MAX_TX_STATUS (defined as 12) was reached. So I reduced the software queue of the ath9k driver from 256 to 12 Packets. 

I'm not sure what you mean. Please send diff with your changes.

> However the performance could be better. Has anyone an idea for another solution or a suggestion to increase the performance?
> 
> Thanks,
> Lukas
> 
>> Hi all,
>>
>> i successfully build up a secure Mesh Network over 20 Nodes with wpa_supplicant, ath9k_htc and linux-kernel 3.18
>>
>> I know there is a limit of station peering's on ath9k_htc, however I whitelisted the stations in a way, that only 7 Peers authenticate with each other.
>>
>> The Mesh Network runs well for about 2 - 3 hours. Then some wireless adapters get stuck and do not response anymore. They need a Powercycle to work again.
>>
>> Has anybody an idea why this happens or what`s the best way to debug such a problem? I don't get any output in syslog.
>>
>> Thanks,
>> Lukas
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> 


-- 
Regards,
Oleksij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20151223/b6a0f157/attachment.pgp 

[ath9k-devel] ath9k_htc over 20 Nodes

[Lukas Göstl]

Hi Oleksij,

---
--- a /drivers/net/wireless/ath/ath9k/hif_usb.h
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.h
@@ -34,7 +34,10 @@
 
 /* FIXME: Verify these numbers (with Windows) */
 #define MAX_TX_URB_NUM  8
-#define MAX_TX_BUF_NUM  256
+/* Decrease BUF_NUM to have the same values for
+ * TX_THRESHOLD in driver and HTC_MAX_TX_STATUS
+ * in firmware. This reduce load on the Adapter */
+#define MAX_TX_BUF_NUM  22
 #define MAX_TX_BUF_SIZE 32768
 #define MAX_TX_AGGR_NUM 20
--

With...
	#define ATH9K_HTC_TX_RESERVE 10
	#define ATH9K_HTC_TX_THRESHOLD (MAX_TX_BUF_NUM - ATH9K_HTC_TX_RESERVE)
... this Patch decreases the ATH9K_HTC_TX_THRESHOLD to 12,  so that the queue has never more than 12 items.

Therefore the cnt for tx_status in the firmware never gets over HTC_MAX_TX_STATUS (defined as 12).

Regards,
Lukas

Am 23.12.2015 um 12:50 schrieb Oleksij Rempel:
> Hi,
> 
> thank you for your testing.
> 
> Am 23.12.2015 um 11:53 schrieb Lukas G?stl:
> > Hi again,
> >
> > I got my Mesh Network running without any of the wireless adapters
> > getting stuck. The Problem was that the adapter got overwhelmed when
> > the ath9k driver wanted to send more packets than the adapter could
> process. More precisely the adapter got Problems when the
> HTC_MAX_TX_STATUS (defined as 12) was reached. So I reduced the
> software queue of the ath9k driver from 256 to 12 Packets.
> 
> I'm not sure what you mean. Please send diff with your changes.
> 
> > However the performance could be better. Has anyone an idea for another
> solution or a suggestion to increase the performance?
> >
> > Thanks,
> > Lukas
> >
> >> Hi all,
> >>
> >> i successfully build up a secure Mesh Network over 20 Nodes with
> >> wpa_supplicant, ath9k_htc and linux-kernel 3.18
> >>
> >> I know there is a limit of station peering's on ath9k_htc, however I
> whitelisted the stations in a way, that only 7 Peers authenticate with each
> other.
> >>
> >> The Mesh Network runs well for about 2 - 3 hours. Then some wireless
> adapters get stuck and do not response anymore. They need a Powercycle to
> work again.
> >>
> >> Has anybody an idea why this happens or what`s the best way to debug
> such a problem? I don't get any output in syslog.
> >>
> >> Thanks,
> >> Lukas
> > _______________________________________________
> > ath9k-devel mailing list
> > ath9k-devel at lists.ath9k.org
> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> >
> 
> 
> --
> Regards,
> Oleksij

[ath9k-devel] ath9k_htc over 20 Nodes

[Oleksij Rempel]

Am 23.12.2015 um 13:28 schrieb Lukas G?stl:
> Hi Oleksij,
> 
> ---
> --- a /drivers/net/wireless/ath/ath9k/hif_usb.h
> +++ b/drivers/net/wireless/ath/ath9k/hif_usb.h
> @@ -34,7 +34,10 @@
>  
>  /* FIXME: Verify these numbers (with Windows) */
>  #define MAX_TX_URB_NUM  8
> -#define MAX_TX_BUF_NUM  256
> +/* Decrease BUF_NUM to have the same values for
> + * TX_THRESHOLD in driver and HTC_MAX_TX_STATUS
> + * in firmware. This reduce load on the Adapter */
> +#define MAX_TX_BUF_NUM  22
>  #define MAX_TX_BUF_SIZE 32768
>  #define MAX_TX_AGGR_NUM 20
> --
> 
> With...
> 	#define ATH9K_HTC_TX_RESERVE 10
> 	#define ATH9K_HTC_TX_THRESHOLD (MAX_TX_BUF_NUM - ATH9K_HTC_TX_RESERVE)
> ... this Patch decreases the ATH9K_HTC_TX_THRESHOLD to 12,  so that the queue has never more than 12 items.
> 
> Therefore the cnt for tx_status in the firmware never gets over HTC_MAX_TX_STATUS (defined as 12).

Interesting,

i need to do some benchtests with changes. Beside, do you get "firmware
panic" notification in dmesg? If no, you will need try latest ath9k code.


> Regards,
> Lukas
> 
> Am 23.12.2015 um 12:50 schrieb Oleksij Rempel:
>> Hi,
>>
>> thank you for your testing.
>>
>> Am 23.12.2015 um 11:53 schrieb Lukas G?stl:
>>> Hi again,
>>>
>>> I got my Mesh Network running without any of the wireless adapters
>>> getting stuck. The Problem was that the adapter got overwhelmed when
>>> the ath9k driver wanted to send more packets than the adapter could
>> process. More precisely the adapter got Problems when the
>> HTC_MAX_TX_STATUS (defined as 12) was reached. So I reduced the
>> software queue of the ath9k driver from 256 to 12 Packets.
>>
>> I'm not sure what you mean. Please send diff with your changes.
>>
>>> However the performance could be better. Has anyone an idea for another
>> solution or a suggestion to increase the performance?
>>>
>>> Thanks,
>>> Lukas
>>>
>>>> Hi all,
>>>>
>>>> i successfully build up a secure Mesh Network over 20 Nodes with
>>>> wpa_supplicant, ath9k_htc and linux-kernel 3.18
>>>>
>>>> I know there is a limit of station peering's on ath9k_htc, however I
>> whitelisted the stations in a way, that only 7 Peers authenticate with each
>> other.
>>>>
>>>> The Mesh Network runs well for about 2 - 3 hours. Then some wireless
>> adapters get stuck and do not response anymore. They need a Powercycle to
>> work again.
>>>>
>>>> Has anybody an idea why this happens or what`s the best way to debug
>> such a problem? I don't get any output in syslog.
>>>>
>>>> Thanks,
>>>> Lukas
>>> _______________________________________________
>>> ath9k-devel mailing list
>>> ath9k-devel at lists.ath9k.org
>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>
>>
>>
>> --
>> Regards,
>> Oleksij
> 


-- 
Regards,
Oleksij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20151223/d996193b/attachment.pgp 

[ath9k-devel] ath9k_htc over 20 Nodes

[Oleksij Rempel]

Am 23.12.2015 um 19:32 schrieb Oleksij Rempel:
> Am 23.12.2015 um 13:28 schrieb Lukas G?stl:
>> Hi Oleksij,
>>
>> ---
>> --- a /drivers/net/wireless/ath/ath9k/hif_usb.h
>> +++ b/drivers/net/wireless/ath/ath9k/hif_usb.h
>> @@ -34,7 +34,10 @@
>>  
>>  /* FIXME: Verify these numbers (with Windows) */
>>  #define MAX_TX_URB_NUM  8
>> -#define MAX_TX_BUF_NUM  256
>> +/* Decrease BUF_NUM to have the same values for
>> + * TX_THRESHOLD in driver and HTC_MAX_TX_STATUS
>> + * in firmware. This reduce load on the Adapter */
>> +#define MAX_TX_BUF_NUM  22
>>  #define MAX_TX_BUF_SIZE 32768
>>  #define MAX_TX_AGGR_NUM 20
>> --
>>
>> With...
>> 	#define ATH9K_HTC_TX_RESERVE 10
>> 	#define ATH9K_HTC_TX_THRESHOLD (MAX_TX_BUF_NUM - ATH9K_HTC_TX_RESERVE)
>> ... this Patch decreases the ATH9K_HTC_TX_THRESHOLD to 12,  so that the queue has never more than 12 items.
>>
>> Therefore the cnt for tx_status in the firmware never gets over HTC_MAX_TX_STATUS (defined as 12).
> 
> Interesting,
> 
> i need to do some benchtests with changes. Beside, do you get "firmware
> panic" notification in dmesg? If no, you will need try latest ath9k code.

No perfomance regression, at least nothing what i can see in my dirty
enviroment test.
What speed do you get? Try ath code, there should be some perf fixes,
and disable LED blinking, it is consuming some USB bandwidth.

>> Regards,
>> Lukas
>>
>> Am 23.12.2015 um 12:50 schrieb Oleksij Rempel:
>>> Hi,
>>>
>>> thank you for your testing.
>>>
>>> Am 23.12.2015 um 11:53 schrieb Lukas G?stl:
>>>> Hi again,
>>>>
>>>> I got my Mesh Network running without any of the wireless adapters
>>>> getting stuck. The Problem was that the adapter got overwhelmed when
>>>> the ath9k driver wanted to send more packets than the adapter could
>>> process. More precisely the adapter got Problems when the
>>> HTC_MAX_TX_STATUS (defined as 12) was reached. So I reduced the
>>> software queue of the ath9k driver from 256 to 12 Packets.
>>>
>>> I'm not sure what you mean. Please send diff with your changes.
>>>
>>>> However the performance could be better. Has anyone an idea for another
>>> solution or a suggestion to increase the performance?
>>>>
>>>> Thanks,
>>>> Lukas
>>>>
>>>>> Hi all,
>>>>>
>>>>> i successfully build up a secure Mesh Network over 20 Nodes with
>>>>> wpa_supplicant, ath9k_htc and linux-kernel 3.18
>>>>>
>>>>> I know there is a limit of station peering's on ath9k_htc, however I
>>> whitelisted the stations in a way, that only 7 Peers authenticate with each
>>> other.
>>>>>
>>>>> The Mesh Network runs well for about 2 - 3 hours. Then some wireless
>>> adapters get stuck and do not response anymore. They need a Powercycle to
>>> work again.
>>>>>
>>>>> Has anybody an idea why this happens or what`s the best way to debug
>>> such a problem? I don't get any output in syslog.
>>>>>
>>>>> Thanks,
>>>>> Lukas
>>>> _______________________________________________
>>>> ath9k-devel mailing list
>>>> ath9k-devel at lists.ath9k.org
>>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>>
>>>
>>>
>>> --
>>> Regards,
>>> Oleksij
>>
> 
> 
> 
> 
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> 


-- 
Regards,
Oleksij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20151224/272ab3ad/attachment.pgp 

[ath9k-devel] ath9k_htc over 20 Nodes

[Lukas Göstl]

Hi Oleksij,

thank you for testing my changes!

I already disabled LED blinking and I?m working with kernel 3.18.19. Are there any significant perf fixes since this kernel version?

I get a speed of 400 to 600 KB/s. It is even worse on devices with bad signal. 
However the tx/rx bitrate of iw wlan0 station dump shows: 
	tx bitrate:	54.0 MBit/s
	rx bitrate:	54.0 MBit/s

Regards,
Lukas

> Am 23.12.2015 um 19:32 schrieb Oleksij Rempel:
> > Am 23.12.2015 um 13:28 schrieb Lukas G?stl:
> >> Hi Oleksij,
> >>
> >> ---
> >> --- a /drivers/net/wireless/ath/ath9k/hif_usb.h
> >> +++ b/drivers/net/wireless/ath/ath9k/hif_usb.h
> >> @@ -34,7 +34,10 @@
> >>
> >>  /* FIXME: Verify these numbers (with Windows) */  #define
> >> MAX_TX_URB_NUM  8 -#define MAX_TX_BUF_NUM  256
> >> +/* Decrease BUF_NUM to have the same values for
> >> + * TX_THRESHOLD in driver and HTC_MAX_TX_STATUS
> >> + * in firmware. This reduce load on the Adapter */ #define
> >> +MAX_TX_BUF_NUM  22
> >>  #define MAX_TX_BUF_SIZE 32768
> >>  #define MAX_TX_AGGR_NUM 20
> >> --
> >>
> >> With...
> >> 	#define ATH9K_HTC_TX_RESERVE 10
> >> 	#define ATH9K_HTC_TX_THRESHOLD (MAX_TX_BUF_NUM -
> >> ATH9K_HTC_TX_RESERVE) ... this Patch decreases the
> ATH9K_HTC_TX_THRESHOLD to 12,  so that the queue has never more than
> 12 items.
> >>
> >> Therefore the cnt for tx_status in the firmware never gets over
> HTC_MAX_TX_STATUS (defined as 12).
> >
> > Interesting,
> >
> > i need to do some benchtests with changes. Beside, do you get
> > "firmware panic" notification in dmesg? If no, you will need try latest ath9k
> code.
> 
> No perfomance regression, at least nothing what i can see in my dirty
> enviroment test.
> What speed do you get? Try ath code, there should be some perf fixes, and
> disable LED blinking, it is consuming some USB bandwidth.
> 
> >> Regards,
> >> Lukas
> >>
> >> Am 23.12.2015 um 12:50 schrieb Oleksij Rempel:
> >>> Hi,
> >>>
> >>> thank you for your testing.
> >>>
> >>> Am 23.12.2015 um 11:53 schrieb Lukas G?stl:
> >>>> Hi again,
> >>>>
> >>>> I got my Mesh Network running without any of the wireless adapters
> >>>> getting stuck. The Problem was that the adapter got overwhelmed
> >>>> when the ath9k driver wanted to send more packets than the adapter
> >>>> could
> >>> process. More precisely the adapter got Problems when the
> >>> HTC_MAX_TX_STATUS (defined as 12) was reached. So I reduced the
> >>> software queue of the ath9k driver from 256 to 12 Packets.
> >>>
> >>> I'm not sure what you mean. Please send diff with your changes.
> >>>
> >>>> However the performance could be better. Has anyone an idea for
> >>>> another
> >>> solution or a suggestion to increase the performance?
> >>>>
> >>>> Thanks,
> >>>> Lukas
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> i successfully build up a secure Mesh Network over 20 Nodes with
> >>>>> wpa_supplicant, ath9k_htc and linux-kernel 3.18
> >>>>>
> >>>>> I know there is a limit of station peering's on ath9k_htc, however
> >>>>> I
> >>> whitelisted the stations in a way, that only 7 Peers authenticate
> >>> with each other.
> >>>>>
> >>>>> The Mesh Network runs well for about 2 - 3 hours. Then some
> >>>>> wireless
> >>> adapters get stuck and do not response anymore. They need a
> >>> Powercycle to work again.
> >>>>>
> >>>>> Has anybody an idea why this happens or what`s the best way to
> >>>>> debug
> >>> such a problem? I don't get any output in syslog.
> >>>>>
> >>>>> Thanks,
> >>>>> Lukas
> >>>> _______________________________________________
> >>>> ath9k-devel mailing list
> >>>> ath9k-devel at lists.ath9k.org
> >>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> >>>>
> >>>
> >>>
> >>> --
> >>> Regards,
> >>> Oleksij
> >>
> >
> >
> >
> >
> > _______________________________________________
> > ath9k-devel mailing list
> > ath9k-devel at lists.ath9k.org
> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> >
> 
> 
> --
> Regards,
> Oleksij

[ath9k-devel] ath9k_htc over 20 Nodes

[Oleksij Rempel]

Am 28.12.2015 um 14:51 schrieb Lukas G?stl:
> Hi Oleksij,
> 
> thank you for testing my changes!
> 
> I already disabled LED blinking and I?m working with kernel 3.18.19. Are there any significant perf fixes since this kernel version?

For example RMW patch this year and syncing big part of ath9k and
ath9k-htc code...

FW has some important fixes as well.

> I get a speed of 400 to 600 KB/s. It is even worse on devices with bad signal. 
> However the tx/rx bitrate of iw wlan0 station dump shows: 
> 	tx bitrate:	54.0 MBit/s
> 	rx bitrate:	54.0 MBit/s
> 

In most tests i have better speed. Only in case for stimulant tcp tx/rx
test i have bad TX speed.

> Regards,
> Lukas
> 
>> Am 23.12.2015 um 19:32 schrieb Oleksij Rempel:
>>> Am 23.12.2015 um 13:28 schrieb Lukas G?stl:
>>>> Hi Oleksij,
>>>>
>>>> ---
>>>> --- a /drivers/net/wireless/ath/ath9k/hif_usb.h
>>>> +++ b/drivers/net/wireless/ath/ath9k/hif_usb.h
>>>> @@ -34,7 +34,10 @@
>>>>
>>>>  /* FIXME: Verify these numbers (with Windows) */  #define
>>>> MAX_TX_URB_NUM  8 -#define MAX_TX_BUF_NUM  256
>>>> +/* Decrease BUF_NUM to have the same values for
>>>> + * TX_THRESHOLD in driver and HTC_MAX_TX_STATUS
>>>> + * in firmware. This reduce load on the Adapter */ #define
>>>> +MAX_TX_BUF_NUM  22
>>>>  #define MAX_TX_BUF_SIZE 32768
>>>>  #define MAX_TX_AGGR_NUM 20
>>>> --
>>>>
>>>> With...
>>>> 	#define ATH9K_HTC_TX_RESERVE 10
>>>> 	#define ATH9K_HTC_TX_THRESHOLD (MAX_TX_BUF_NUM -
>>>> ATH9K_HTC_TX_RESERVE) ... this Patch decreases the
>> ATH9K_HTC_TX_THRESHOLD to 12,  so that the queue has never more than
>> 12 items.
>>>>
>>>> Therefore the cnt for tx_status in the firmware never gets over
>> HTC_MAX_TX_STATUS (defined as 12).
>>>
>>> Interesting,
>>>
>>> i need to do some benchtests with changes. Beside, do you get
>>> "firmware panic" notification in dmesg? If no, you will need try latest ath9k
>> code.
>>
>> No perfomance regression, at least nothing what i can see in my dirty
>> enviroment test.
>> What speed do you get? Try ath code, there should be some perf fixes, and
>> disable LED blinking, it is consuming some USB bandwidth.
>>
>>>> Regards,
>>>> Lukas
>>>>
>>>> Am 23.12.2015 um 12:50 schrieb Oleksij Rempel:
>>>>> Hi,
>>>>>
>>>>> thank you for your testing.
>>>>>
>>>>> Am 23.12.2015 um 11:53 schrieb Lukas G?stl:
>>>>>> Hi again,
>>>>>>
>>>>>> I got my Mesh Network running without any of the wireless adapters
>>>>>> getting stuck. The Problem was that the adapter got overwhelmed
>>>>>> when the ath9k driver wanted to send more packets than the adapter
>>>>>> could
>>>>> process. More precisely the adapter got Problems when the
>>>>> HTC_MAX_TX_STATUS (defined as 12) was reached. So I reduced the
>>>>> software queue of the ath9k driver from 256 to 12 Packets.
>>>>>
>>>>> I'm not sure what you mean. Please send diff with your changes.
>>>>>
>>>>>> However the performance could be better. Has anyone an idea for
>>>>>> another
>>>>> solution or a suggestion to increase the performance?
>>>>>>
>>>>>> Thanks,
>>>>>> Lukas
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> i successfully build up a secure Mesh Network over 20 Nodes with
>>>>>>> wpa_supplicant, ath9k_htc and linux-kernel 3.18
>>>>>>>
>>>>>>> I know there is a limit of station peering's on ath9k_htc, however
>>>>>>> I
>>>>> whitelisted the stations in a way, that only 7 Peers authenticate
>>>>> with each other.
>>>>>>>
>>>>>>> The Mesh Network runs well for about 2 - 3 hours. Then some
>>>>>>> wireless
>>>>> adapters get stuck and do not response anymore. They need a
>>>>> Powercycle to work again.
>>>>>>>
>>>>>>> Has anybody an idea why this happens or what`s the best way to
>>>>>>> debug
>>>>> such a problem? I don't get any output in syslog.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Lukas
>>>>>> _______________________________________________
>>>>>> ath9k-devel mailing list
>>>>>> ath9k-devel at lists.ath9k.org
>>>>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Oleksij
>>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> ath9k-devel mailing list
>>> ath9k-devel at lists.ath9k.org
>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>
>>
>>
>> --
>> Regards,
>> Oleksij
> 


-- 
Regards,
Oleksij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20151228/dfec606c/attachment.pgp