ath9k_htc kernel driver regression affecting throughput

ath9k_htc kernel driver regression affecting throughput

[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

Re: ath9k_htc kernel driver regression affecting throughput

[Oleksij Rempel]

[-- Attachment #1.1: Type: text/plain, Size: 1588 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: ath9k_htc kernel driver regression affecting throughput

[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.

On 9/20/16, Oleksij Rempel <linux@rempel-privat.de> 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
>
>

Re: ath9k_htc kernel driver regression affecting throughput

[Ben Greear]

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 <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ath9k_htc kernel driver regression affecting throughput

[bruce m beach]

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 <greearb@candelatech.com> 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 <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>

Re: ath9k_htc kernel driver regression affecting throughput

[Ben Greear]

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 <greearb@candelatech.com> 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 <greearb@candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>
>

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ath9k_htc kernel driver regression affecting throughput

[Oleksij Rempel]

[-- Attachment #1.1: Type: text/plain, Size: 485 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: ath9k_htc kernel driver regression affecting throughput

[Oleksij Rempel]

[-- Attachment #1.1: Type: text/plain, Size: 960 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: ath9k_htc kernel driver regression affecting throughput

[Oleksij Rempel]

[-- Attachment #1.1: Type: text/plain, Size: 782 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

ath9k_htc kernel driver regression affecting throughput

[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