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 signature.asc Description: OpenPGP digital signature
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 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 Candela Technologies Inc http://www.candelatech.com -- Ben Greear Candela Technologies Inc http://www.candelatech.com
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 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 > Candela Technologies Inc http://www.candelatech.com >
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 Candela Technologies Inc http://www.candelatech.com
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 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
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 signature.asc Description: OpenPGP digital signature
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 signature.asc Description: OpenPGP digital signature
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 signature.asc Description: OpenPGP digital signature