OpenWrt Forum Archive

Topic: Update on Linksys WRT1900AC support

The content of this topic has been archived between 16 Sep 2014 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.

InkblotAdmirer wrote:

My observations so far (comparing driver 17 vs driver 16):

2.4G file transfers maybe 33% slower (12MB/s rather than 18ish)
5G file transfers are erratic but typically very poor (3MB/s, slowing below and I've seen bursts up to 30MB/s toward the tail end of large file transfers)

5G performance with iperf3:  VHT80 I get 260-280 Mb/s to a distant WRT1900, 480Mb/s to an Android phone
No linux clients on the other end of the 2.4G so no iperf data

I have the 5G between WRT1900s set up as client and AP.  If I run the AP as server (or use -R flag from AP running as client) I get 1.1Mbps.  I saw that with driver 16 as well.

So here is something you don't see everyday....

I spent the evening trying to merge the 120-chatdster_fix.patch with .17, but things were not going well...

This morning I decided to start fresh:

1. Removed that patch from the /target/Linux/mvebu/pathches-4.4
2. Ran make clean and make V=s hoping to start with a clean build

I looked in /bild-dir/../linux-mvebu/mwlwifi-10.3.0.17-20160324, and started comparing the files against
the patch and source @ https://github.com/kaloz/mwlwifi

To my great surprise, all the changes from the patch somehow made their way into the files in the /buld-dir/../mwlwifi-10.3.0.17-20160324 directory i.e. dev.h, fwcmd.c, fwdl.c, and main.c

A quick sysupgrade later to both 1900AC v1s, and my speed and latency are back to where we were on .16

The "hybrid" kmod-mwlwifi_4.4.6+10.3.0.17-20160324-1.ipk is 230 kb in size, which is smaller than the .17 if I remember correctly...

If anyone want to see the contents of the /buld-dir/../mwlwifi-10.3.0.17-20160324 directory or the ipk itself, I can share them no problem...

Any thoughts on what may have happened here would be welcome smile

Cheers

doITright wrote:
InkblotAdmirer wrote:

My observations so far (comparing driver 17 vs driver 16):

2.4G file transfers maybe 33% slower (12MB/s rather than 18ish)
5G file transfers are erratic but typically very poor (3MB/s, slowing below and I've seen bursts up to 30MB/s toward the tail end of large file transfers)

5G performance with iperf3:  VHT80 I get 260-280 Mb/s to a distant WRT1900, 480Mb/s to an Android phone
No linux clients on the other end of the 2.4G so no iperf data

I have the 5G between WRT1900s set up as client and AP.  If I run the AP as server (or use -R flag from AP running as client) I get 1.1Mbps.  I saw that with driver 16 as well.

So here is something you don't see everyday....

I spent the evening trying to merge the 120-chatdster_fix.patch with .17, but things were not going well...

This morning I decided to start fresh:

1. Removed that patch from the /target/Linux/mvebu/pathches-4.4
2. Ran make clean and make V=s hoping to start with a clean build

I looked in /bild-dir/../linux-mvebu/mwlwifi-10.3.0.17-20160324, and started comparing the files against
the patch and source @ https://github.com/kaloz/mwlwifi

To my great surprise, all the changes from the patch somehow made their way into the files in the /buld-dir/../mwlwifi-10.3.0.17-20160324 directory i.e. dev.h, fwcmd.c, fwdl.c, and main.c

A quick sysupgrade later to both 1900AC v1s, and my speed and latency are back to where we were on .16

The "hybrid" kmod-mwlwifi_4.4.6+10.3.0.17-20160324-1.ipk is 230 kb in size, which is smaller than the .17 if I remember correctly...

If anyone want to see the contents of the /buld-dir/../mwlwifi-10.3.0.17-20160324 directory or the ipk itself, I can share them no problem...

Any thoughts on what may have happened here would be welcome smile

Cheers

Yeah i tried reading the patch and most of it was mainlined, the main difference is in fwdl.c and fwcmd.c

lifehacksback wrote:

Yeah i tried reading the patch and most of it was mainlined, the main difference is in fwdl.c and fwcmd.c

I nuked the whole thing and cloned again... 

building now with just the nand and buffer manager patches...

Will verify again.... 

Something in there made my wireless N @ 2.4 GHz almost useless the first time at .17 and I would like to know more.

Cheers

doITright wrote:
lifehacksback wrote:

Yeah i tried reading the patch and most of it was mainlined, the main difference is in fwdl.c and fwcmd.c

I nuked the whole thing and cloned again... 

building now with just the nand and buffer manager patches...

Will verify again.... 

Something in there made my wireless N @ 2.4 GHz almost useless the first time at .17 and I would like to know more.

Cheers

Are you building with kernel 4.4.6?

davidc502 wrote:

Are you building with kernel 4.4.6?

Only with 4.4.6

Have not even tried the lower kernels since December or so (since the NAND issues first hit us).

Cheers

doITright wrote:
davidc502 wrote:

Are you building with kernel 4.4.6?

Only with 4.4.6

Have not even tried the lower kernels since December or so (since the NAND issues first hit us).

Cheers

Can you share buffer manager patches?  Since pulling the latest snapshot I've been unable to compile them due to an error.

OR did you find a work around or what the problem is with line 73 "depends on PLAT_ORION"?
mvneta_mvneta-bm.patch

Actually, I'm surprised 4.4.6 has worked so well.... I was very hesitant to trying another newer kernel, but it's actually worked out well so far.

(Last edited by davidc502 on 27 Mar 2016, 21:45)

I've read through a fair portion of the thread and didn't see anything like this so hopefully I am not repeating a question. I am running the new snapshot from David with the .17 driver on Mamba hardware but my upload speed on AC is very slow. I can get download speeds around 100-200 Mbit/s but my upload speeds hang around 500 kbit/s. I can get pretty decent speeds if I set the 5 GHz radio to N but on AC it acts up like that. I have tried 20, 40 and 80 width but see the same thing. Hopefully that's all the information that is relevant.

Thanks

It was slow for me too when I first flashed... I changed from 80mhz to 40, and then rebooted the router and my devices... From there speeds on 5Ghz went back up, and I then changed back to 80mhz, and no issues from there.

I have no idea why it was initially slow.

davidc502 wrote:
doITright wrote:
davidc502 wrote:

Are you building with kernel 4.4.6?

Only with 4.4.6

Have not even tried the lower kernels since December or so (since the NAND issues first hit us).

Cheers

Can you share buffer manager patches?  Since pulling the latest snapshot I've been unable to compile them due to an error.

OR did you find a work around or what the problem is with line 73 "depends on PLAT_ORION"?
mvneta_mvneta-bm.patch

Actually, I'm surprised 4.4.6 has worked so well.... I was very hesitant to trying another newer kernel, but it's actually worked out well so far.

I could not get the patches from @nitroshift to work either.... 

but the ones from @mrfreeze were perfect

Here is the link to all the 4.4.6 patches I use:

https://www.dropbox.com/sh/ff57qijgv9w3 … iGnOa?dl=0

Cheers

doITright wrote:
davidc502 wrote:
doITright wrote:

Only with 4.4.6

Have not even tried the lower kernels since December or so (since the NAND issues first hit us).

Cheers

Can you share buffer manager patches?  Since pulling the latest snapshot I've been unable to compile them due to an error.

OR did you find a work around or what the problem is with line 73 "depends on PLAT_ORION"?
mvneta_mvneta-bm.patch

Actually, I'm surprised 4.4.6 has worked so well.... I was very hesitant to trying another newer kernel, but it's actually worked out well so far.

I could not get the patches from @nitroshift to work either.... 

but the ones from @mrfreeze were perfect

Here is the link to all the 4.4.6 patches I use:

https://www.dropbox.com/sh/ff57qijgv9w3 … iGnOa?dl=0

Cheers

Using the same patches... Except now with the newest snapshot, it fails. 905 patch - malformed patch at line 73: depends on PLAT_ORION

I'm not sure what's going on here.

davidc502 wrote:
doITright wrote:
davidc502 wrote:

Can you share buffer manager patches?  Since pulling the latest snapshot I've been unable to compile them due to an error.

OR did you find a work around or what the problem is with line 73 "depends on PLAT_ORION"?
mvneta_mvneta-bm.patch

Actually, I'm surprised 4.4.6 has worked so well.... I was very hesitant to trying another newer kernel, but it's actually worked out well so far.

I could not get the patches from @nitroshift to work either.... 

but the ones from @mrfreeze were perfect

Here is the link to all the 4.4.6 patches I use:

https://www.dropbox.com/sh/ff57qijgv9w3 … iGnOa?dl=0

Cheers

Using the same patches... Except now with the newest snapshot, it fails. 905 patch - malformed patch at line 73: depends on PLAT_ORION

I'm not sure what's going on here.

did u use the hw acceleration zip? then just extracted to patches on mwlwifi? delete 120-chadster_fix.patch. and b4 all this run a make clean, the make menuconfig. made sure it was on kernel 4.4 with nand patch?

lifehacksback wrote:

did u use the hw acceleration zip? then just extracted to patches on mwlwifi? delete 120-chadster_fix.patch. and b4 all this run a make clean, the make menuconfig. made sure it was on kernel 4.4 with nand patch?

hang on a sec....

delete 120 I get (if it interferes)....  make clean I get... 

but why run menuconfig? Is there something to be selected in there?

Thanks

lifehacksback wrote:

did u use the hw acceleration zip? then just extracted to patches on mwlwifi? delete 120-chadster_fix.patch. and b4 all this run a make clean, the make menuconfig. made sure it was on kernel 4.4 with nand patch?

This is what I've done.

Downloaded 4.4.6 patches

Discarded 980 nand.patch << I already have nand patch

Extracted the rest of the patches to > /openwrt/target/linux/mvebu/patches4.4/   
The MakeFile has already been altered to point to Kernel 4.4


make clean
make menuconfig  > made selections and saved
make V=s

(Last edited by davidc502 on 28 Mar 2016, 01:05)

hi,

i have a WRT1900ACS (NO fan) with OpenWRT (latest trunk).

My temperatures seems to be pretty high:

root@OpenWrt:~# sensors
tmp421-i2c-0-4c
Adapter: mv64xxx_i2c adapter
temp1:        +51.9°C 
temp2:        +53.8°C 

armada_thermal-virtual-0
Adapter: Virtual device
temp1:        +80.8°C 

Are these temps normal? How high are your temperatures?

Thanks!

con wrote:

hi,

i have a WRT1900ACS (NO fan) with OpenWRT (latest trunk).

My temperatures seems to be pretty high:

root@OpenWrt:~# sensors
tmp421-i2c-0-4c
Adapter: mv64xxx_i2c adapter
temp1:        +51.9°C 
temp2:        +53.8°C 

armada_thermal-virtual-0
Adapter: Virtual device
temp1:        +80.8°C 

Are these temps normal? How high are your temperatures?

Thanks!

Normal depends on many things such as ambient room temperature as well as how much you are pushing thru your wireless, how many wireless clients...

I have pushed my WRT1200AC(no fan) as high as ~79-80°C.  But that was during some testing and normalizes around 75°C ish.

(Last edited by kirkgbr on 28 Mar 2016, 02:13)

This is my experience my the latest driver. I started building DD trunk 49066 (kernel 4.4.6) with .16 driver. I did iperf3 from intel 3160 iwlwifi from linux machine. I got the average 220-230 Mbps to internal gigabit lan to one of the port for my other machine. My android phone got the average 270-280Mbps.

Once I did the above test, I built kmod kernel module package for .17 driver then apply it through opkg update. My test is very similar with .16 driver.

How did everyone do the test to get the 20-30% improvement between .16 vs .17 driver?

@e88z4

Basically throughput should be almost the same for .16 and .17. But .17 fixes two problems:
1. Fixed problem: tx throughput will become lower after running for a while.
2. Fixed problme: multicast out-of-order.

For .16, if you run the wifi for a period of time, you will get poor throughput.

BTW, when problem 1 happened, if you run iperf UDP test, you will get out-of-order packets no matter unicast or multicast.

(Last edited by dlin on 28 Mar 2016, 04:34)

@doITright

I wonder where can I get 120-chadster_fix.patch? Thanks.

doITright wrote:
dlin wrote:

@doITright

I wonder where can I get 120-chadster_fix.patch? Thanks.

you can find it in the "mwlwifi .16 driver patch directory" at:

https://www.dropbox.com/sh/ff57qijgv9w3 … iGnOa?dl=0

Cheers

I can't access the link.

(Last edited by dlin on 28 Mar 2016, 07:03)

@muronghan: did you have time to test the wifi issue with 2 ssids on 1 radio? I already packed away my device, but if the error is gone, I will give it a try!

thx!

Just woke up and my build was finished. I flashed and it works like a charm, will provide some feedback on Wireless performance soon.

Edit: I don't know if it take too much time for you to rebuild the toolchain and everything but i suggest to nuke (make distclean) each time there is a major build error (like a diff mismatch or a failed "new" feature). Always solve the problem for me.

(Last edited by mrfrezee on 28 Mar 2016, 08:12)

@davidc502 yuhhaurlin asked me if the latest firmware is used in combination with the .17 wifi driver. I am not sure what he is refering to. May be you can answer this one. I will then relay the answer to him. Thanks.

Bit confused by all this stuff, can someone just link me a good solid firmware file? Currently using the standard one from the page, i have v2.

Sorry, posts 10501 to 10500 are missing from our archive.