2016-09-17 15:52:36

by bruce m beach

[permalink] [raw]
Subject: ath9k_htc kernel driver regression affecting throughput

>> Hm.. found here one report about bad perfomance on this driver
>> https://ubuntuforums.org/showthread.php?t=2312343
>>
>> affected persons seems to use WEP encryption.
>>
>> What encryption do are you using?

I just wish I could do some testing on a single machine. Every test
suite I've seen always involves 2 machines. Why can't I use the wifi
chip on the mother board and the ar9271(a usb stick) to test basic
communications on the ar9271. The problem is I don't know where to begin.

Bruce


2016-09-21 04:31:03

by Oleksij Rempel

[permalink] [raw]
Subject: Re: ath9k_htc kernel driver regression affecting throughput

Am 21.09.2016 um 05:43 schrieb bruce m beach:
> Oleksij
>
> I looked at
> https://unix.stackexchange.com/questions/122050/
> send-traffic-to-self-over-physical-network-on-ubuntu
>
> It appearred to too complicated but
>
> https://unix.stackexchange.com/questions/122050/
> send-traffic-to-self-over-physical-network-on-ubuntu
> with:
> # Create a network namespace and move one of interfaces into it:
> ip netns add test2
> ip link set wlan0 netns test2
> # Start a shell in the new namespace:
> ip netns exec test2 bash
> # Then proceed as if you had two machines. When finished exit the shell and
> # delete the namespace:
> ip netns del test2
> Certainly looks interesting but after I got a
> RTNETLINK answers: Invalid argument
> I lost interest. My heart isn't in it. I'm still working on the firmware. I
> have started a new tree (tree #3) that consists of a userland firmware uploader
> and until recently the following firmware:
>
> app_start( void ) {}
>
> i.e a lable that the code jumps to and nothing else. At this point I have
> added VendorCommand(), and a debugger via ep0. ( ep0 is a good choice
> since it is available a boot, no matter what) and over the next few
> months I am going to move ->all<- the rom code into ram starting with
> the USB subsystem.
>
> Bruce
>


Wow, this sounds interesting :)
We recently updated FW to GCC 6.2 which can detect more problems. So it
will be probably interesting for you to pick this patch out.

--
Regards,
Oleksij


Attachments:
signature.asc (213.00 B)
OpenPGP digital signature

2016-09-22 13:34:56

by Ben Greear

[permalink] [raw]
Subject: Re: ath9k_htc kernel driver regression affecting throughput



On 09/21/2016 09:53 PM, bruce m beach wrote:
> memory will be very tight. There is 160k or known ram and bits and pieces
> elsewhere. The rom is 24k (maximum). I currently am not to worried about
> it. (although I am watching it)
> bruce

Probably you know this...but check structs for memory holes, unused
fields (write only, for instance) and other wastes.
ath10k firmware was full of needless memory bloat in those areas.

Global pointers can be used in some cases to help, but mysteriously
seem to cause more instruction RAM in some cases.

Watch 'instruction ram' usage: Changing code to use a bitfield may save
some BSS ram, but may easily use far more instruction ram than what you
saved with the bitfield.

Good luck!

Thanks,
Ben

>
> On 9/21/16, Ben Greear <[email protected]> wrote:
>>
>>
>> On 09/21/2016 08:34 PM, bruce m beach wrote:
>>
>>>>> i.e a lable that the code jumps to and nothing else. At this point I
>>>>> have
>>>>> added VendorCommand(), and a debugger via ep0. ( ep0 is a good choice
>>>>> since it is available a boot, no matter what) and over the next few
>>>>> months I am going to move ->all<- the rom code into ram starting with
>>>>> the USB subsystem.
>>
>> Have you investigated whether you have enough RAM to do this?
>>
>> I haven't looked at ath9k_htc, but in general, that type of architecture
>> is tight on RAM in my experience.
>>
>> Thanks,
>> Ben
>>
>> --
>> Ben Greear <[email protected]>
>> Candela Technologies Inc http://www.candelatech.com
>>
>

--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com

2016-09-22 04:53:31

by bruce m beach

[permalink] [raw]
Subject: Re: ath9k_htc kernel driver regression affecting throughput

memory will be very tight. There is 160k or known ram and bits and pieces
elsewhere. The rom is 24k (maximum). I currently am not to worried about
it. (although I am watching it)
bruce

On 9/21/16, Ben Greear <[email protected]> wrote:
>
>
> On 09/21/2016 08:34 PM, bruce m beach wrote:
>
>>>> i.e a lable that the code jumps to and nothing else. At this point I
>>>> have
>>>> added VendorCommand(), and a debugger via ep0. ( ep0 is a good choice
>>>> since it is available a boot, no matter what) and over the next few
>>>> months I am going to move ->all<- the rom code into ram starting with
>>>> the USB subsystem.
>
> Have you investigated whether you have enough RAM to do this?
>
> I haven't looked at ath9k_htc, but in general, that type of architecture
> is tight on RAM in my experience.
>
> Thanks,
> Ben
>
> --
> Ben Greear <[email protected]>
> Candela Technologies Inc http://www.candelatech.com
>

2016-09-22 03:34:49

by bruce m beach

[permalink] [raw]
Subject: Re: ath9k_htc kernel driver regression affecting throughput

> We recently updated FW to GCC 6.2 which can detect more problems. So it
> will be probably interesting for you to pick this patch out.

Yes I saw the message by Adrian Chadd and tried tried to git clone the link
he gave but that clearly wasn't what was to be done. Is there a patch that I
need to apply to the firmware? I do have a local copy.

On 9/20/16, Oleksij Rempel <[email protected]> wrote:
> Am 21.09.2016 um 05:43 schrieb bruce m beach:
>> Oleksij
>>
>> I looked at
>> https://unix.stackexchange.com/questions/122050/
>> send-traffic-to-self-over-physical-network-on-ubuntu
>>
>> It appearred to too complicated but
>>
>> https://unix.stackexchange.com/questions/122050/
>> send-traffic-to-self-over-physical-network-on-ubuntu
>> with:
>> # Create a network namespace and move one of interfaces into it:
>> ip netns add test2
>> ip link set wlan0 netns test2
>> # Start a shell in the new namespace:
>> ip netns exec test2 bash
>> # Then proceed as if you had two machines. When finished exit the
>> shell and
>> # delete the namespace:
>> ip netns del test2
>> Certainly looks interesting but after I got a
>> RTNETLINK answers: Invalid argument
>> I lost interest. My heart isn't in it. I'm still working on the firmware.
>> I
>> have started a new tree (tree #3) that consists of a userland firmware
>> uploader
>> and until recently the following firmware:
>>
>> app_start( void ) {}
>>
>> i.e a lable that the code jumps to and nothing else. At this point I have
>> added VendorCommand(), and a debugger via ep0. ( ep0 is a good choice
>> since it is available a boot, no matter what) and over the next few
>> months I am going to move ->all<- the rom code into ram starting with
>> the USB subsystem.
>>
>> Bruce
>>
>
>
> Wow, this sounds interesting :)
> We recently updated FW to GCC 6.2 which can detect more problems. So it
> will be probably interesting for you to pick this patch out.
>
> --
> Regards,
> Oleksij
>
>

2016-09-17 16:14:59

by Oleksij Rempel

[permalink] [raw]
Subject: Re: ath9k_htc kernel driver regression affecting throughput

Am 17.09.2016 um 17:52 schrieb bruce m beach:
>>> Hm.. found here one report about bad perfomance on this driver
>>> https://ubuntuforums.org/showthread.php?t=2312343
>>>
>>> affected persons seems to use WEP encryption.
>>>
>>> What encryption do are you using?
>
> I just wish I could do some testing on a single machine. Every test
> suite I've seen always involves 2 machines. Why can't I use the wifi
> chip on the mother board and the ar9271(a usb stick) to test basic
> communications on the ar9271. The problem is I don't know where to begin.
>
> Bruce
>

i didn't tried it myself:
https://unix.stackexchange.com/questions/122050/send-traffic-to-self-over-physical-network-on-ubuntu

but last suggestion looks interesting.

--
Regards,
Oleksij


Attachments:
signature.asc (213.00 B)
OpenPGP digital signature

2016-09-22 17:12:16

by Oleksij Rempel

[permalink] [raw]
Subject: Re: ath9k_htc kernel driver regression affecting throughput

Am 22.09.2016 um 05:34 schrieb bruce m beach:
>> We recently updated FW to GCC 6.2 which can detect more problems. So it
>> will be probably interesting for you to pick this patch out.
>
> Yes I saw the message by Adrian Chadd and tried tried to git clone the link
> he gave but that clearly wasn't what was to be done. Is there a patch that I
> need to apply to the firmware? I do have a local copy.
>

this patches are now in main repository.

--
Regards,
Oleksij


Attachments:
signature.asc (213.00 B)
OpenPGP digital signature

2016-09-22 04:18:51

by Ben Greear

[permalink] [raw]
Subject: Re: ath9k_htc kernel driver regression affecting throughput



On 09/21/2016 08:34 PM, bruce m beach wrote:

>>> i.e a lable that the code jumps to and nothing else. At this point I have
>>> added VendorCommand(), and a debugger via ep0. ( ep0 is a good choice
>>> since it is available a boot, no matter what) and over the next few
>>> months I am going to move ->all<- the rom code into ram starting with
>>> the USB subsystem.

Have you investigated whether you have enough RAM to do this?

I haven't looked at ath9k_htc, but in general, that type of architecture
is tight on RAM in my experience.

Thanks,
Ben

--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com

2016-09-17 16:24:08

by Oleksij Rempel

[permalink] [raw]
Subject: Re: ath9k_htc kernel driver regression affecting throughput

Am 17.09.2016 um 18:14 schrieb Oleksij Rempel:
> Am 17.09.2016 um 17:52 schrieb bruce m beach:
>>>> Hm.. found here one report about bad perfomance on this driver
>>>> https://ubuntuforums.org/showthread.php?t=2312343
>>>>
>>>> affected persons seems to use WEP encryption.
>>>>
>>>> What encryption do are you using?
>>
>> I just wish I could do some testing on a single machine. Every test
>> suite I've seen always involves 2 machines. Why can't I use the wifi
>> chip on the mother board and the ar9271(a usb stick) to test basic
>> communications on the ar9271. The problem is I don't know where to begin.
>>
>> Bruce
>>
>
> i didn't tried it myself:
> https://unix.stackexchange.com/questions/122050/send-traffic-to-self-over-physical-network-on-ubuntu
>
> but last suggestion looks interesting.
>

or this:
https://www.spinics.net/lists/netdev/msg152621.html

please share if you get it work :D

--
Regards,
Oleksij


Attachments:
signature.asc (213.00 B)
OpenPGP digital signature