For those who want to jump up to the 3200acm without spending a lot of money, here's a flea-bay deal of the day....  $119.00 w/ Free Shipping and no taxes.

Staples seems to be in on the action too.

Both qos and sqm can be included without interfering with each other, as long as only one of them is activated.
Sqm is the easier one to setup and probably better suited for the average user.
Qos allows more fine control over the way to control and prioritize traffic, but would require more knowledge of the process.
If you have to choose one, I'd say keep sqm, but since the WRT series have plenty of flash, I don't se any problem keeping both included as standard.

Hi I thought that SQM was built to combat the short comings of qos.

davidc502 wrote:

bytchslappa wrote:

This might be a strange question - I'm still running a 1900acv1 - on r5113 - stable as a stable thing - what is the max WAN speed people have seen on these routers.. I've got a 1Gigabit connection - but seeing a whole 200mbps coming down the pipe...

A couple of years ago I owned the v1. At times, depending on the build, I could get 650mbps to 800mbps. There was always this issue with IRQ balancing. Most of the times 1 cpu would handle the entire load, and when that happened I could only get around maybe 400mbps.  The other and main issue of why it isn't able to get 1Gbps was due to the lack of hardware acceleration. Over the years there have been several people who have tried to patch and get it working, but nothing really stuck, and nothing ever reached trunk for distribution. At least that's what I remember.

200Mbps seems a little low even if IRQ balancing isn't working.  Run htop whist doing a speed test and see if 1 processor gets maxed out. Also, for a test, you might check the latest build. The latest build (r6302) will have reboot issues, but I'm curious if some of the processor changes to keep it from rebooting on r5113 is killing throughput.

Do a few speed tests with it and then revert back to r5113.

Yip - A CPU core is pegging during the speed test - the second core hits around 50%-60% with r5113... will roll back to stock and test, and upgrade to r6302 and test..

Thanks

bytchslappa wrote:

davidc502 wrote:

A couple of years ago I owned the v1. At times, depending on the build, I could get 650mbps to 800mbps. There was always this issue with IRQ balancing. Most of the times 1 cpu would handle the entire load, and when that happened I could only get around maybe 400mbps.  The other and main issue of why it isn't able to get 1Gbps was due to the lack of hardware acceleration. Over the years there have been several people who have tried to patch and get it working, but nothing really stuck, and nothing ever reached trunk for distribution. At least that's what I remember.

200Mbps seems a little low even if IRQ balancing isn't working.  Run htop whist doing a speed test and see if 1 processor gets maxed out. Also, for a test, you might check the latest build. The latest build (r6302) will have reboot issues, but I'm curious if some of the processor changes to keep it from rebooting on r5113 is killing throughput.

Do a few speed tests with it and then revert back to r5113.

Yip - A CPU core is pegging during the speed test - the second core hits around 50%-60% with r5113... will roll back to stock and test, and upgrade to r6302 and test..

Thanks

So finally got around to some speed testing after working out my ISP had provisioned my connection all wrong but here goes: (these are LAN speeds tested across multiple machines)

With r5032 (dated 2017-10-19) - max speed 190mbps download 80mbps upload 4ms ping
Stock Stock Linksys - max speed 901mbps download 500mbps upload 1ms ping (pretty much the max speed that can be delivered)
With 6302 - max speed 277mbps download 333mbps upload (wtf) 2ms ping (rebooted after 30mins)

I'm not doing anything trick with the firmware - its got no added packages, no nas connections etc.. with LEDE based I do notice that I am getting a higher connection rate to wireless (866mbps vs 400mbps for example on my note 8) - but - the actual speed is less than stock..

While I love all the extra tricks of the open source firmware - and all the hard work that goes into it - for the 1900ac i can't ignore that performance difference with throughput..

Has anyone done this sort of testing with the 3200 with a high speed connection?

For those interested - New Zealand has been rolling out gigabit fiber for a while now - this plan costs $NZ99 or $70US for unlimited data....

@bytchslappa

I am seeing consistent 930Mbps up and down on both my 3200's running on kernel 4.14. That's on a gigabit FTTH connection for which I pay 8 EUR. Netdata shows 1% CPU load during tests so kmod-ipt-offload does its job nicely.

nitroshift

A new experimental build has been uploaded to the server and is ready to be downloaded. It is based on kernel 4.14.23. According to the latest commits, this is now the 'default' kernel for our model series. Rather than just jump into it, I thought it would be a good idea to do some testing and hear feedback from users before making it a regular build. The last experimental build had wifi issues especially for V2 owners, so I'm interested to hear if those problems continue of if they have now been fixed. I suspect they have indeed been fixed.

Patch 005 has been added to the build, so the very latest 3200acm hardware can enjoy this firmware as well.
I did not hack the wifi driver for the 1200acm this time. I'm interested to hear from 1200acm users if they still experience latency or high ping times when playing games etc. If the issue continues, I will continue to make changes to the driver to accommodate 1200ac owners. 

Kernel 4.14.23 with the latest wifi driver commit.
https://davidc502sis.dynamic-dns.net/sn … u/generic/

Sorry V1 owners, the reboot issue continues with this kernel.

davidc502 wrote:

A new experimental build has been uploaded to the server and is ready to be downloaded. It is based on kernel 4.14.23. According to the latest commits, this is now the 'default' kernel for our model series. Rather than just jump into it, I thought it would be a good idea to do some testing and hear feedback from users before making it a regular build. The last experimental build had wifi issues especially for V2 owners, so I'm interested to hear if those problems continue of if they have now been fixed. I suspect they have indeed been fixed.

Patch 005 has been added to the build, so the very latest 3200acm hardware can enjoy this firmware as well.
I did not hack the wifi driver for the 1200acm this time. I'm interested to hear from 1200acm users if they still experience latency or high ping times when playing games etc. If the issue continues, I will continue to make changes to the driver to accommodate 1200ac owners. 

Kernel 4.14.23 with the latest wifi driver commit.
https://davidc502sis.dynamic-dns.net/sn … u/generic/

Sorry V1 owners, the reboot issue continues with this kernel.

Hey David!

Long time no see!  Been wayyy too busy with work.

I haven't upgraded since r5501 in December.  No need to; been working great.

However, I will try this experimental release since I finally have the time to do something besides work

Two questions for you:

a) You mentioned you didn't modify the wifi driver in the build to disable AMSDU (latency and high ping issue).  However, you only ask for 1200ac owners to report back.  That ping/latency issue (more specifically AMSDU malfunctioning) affects all 88W8864 models (everything but the 3200acm).  Unless did something change?  Regardless I'll report back and let you know if it is still needed.

b) Looks like there have been a few new commits on mwlwifi since March 5th, including one specifically for the 88W8864 to fix a crash, one other of significance, and lastly one that updated the version number.  Could you release an updated mwlwifi driver for your r6365 experimental build?

Edit: I guess there really is no need for you to compile the driver with the mod to disable AMSDU to fix the ping/latency issue (if it still exists -- my guess is it does unless the kernel bump had something to do with it -- don't see any commits on mwlwifi).  AMSDU can be disabled by the following commands which need to be executed at boot-up in a script, etc.  @yuhhaurlin had added this a few months ago.  They MUST be executed before any wifi devices connect:

echo 0 > /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
echo 0 > /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu

and then you can run

cat /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu

to confirm it is off.

b. That's a interesting question. With kernel 4.14, the very latest wifi commit, I can use, is from March 5th. There is a patch that work to fix an issue with kernel 4.14, but on the 6th yuhhaurlin does a commit that seems to break the patch. If you remove the patch then all seems to go fine. However, after flashing the image wifi will not work.  So, at this point I'm waiting to hear if others are having issues from the daily build and if there is anyone looking to correct the problem.   << Hope that makes sense.

davidc502 wrote:

b. That's a interesting question. With kernel 4.14, the very latest wifi commit, I can use, is from March 5th. There is a patch that work to fix an issue with kernel 4.14, but on the 6th yuhhaurlin does a commit that seems to break the patch. If you remove the patch then all seems to go fine. However, after flashing the image wifi will not work.  So, at this point I'm waiting to hear if others are having issues from the daily build and if there is anyone looking to correct the problem.   << Hope that makes sense.

Have you tried making a build with Kernel 4.14 from the wifi commit https://github.com/kaloz/mwlwifi/commit … 27362ebe0, and also deleting package/kernel/mwlwifi/patches/001-remove-vfs_write.patch?

Judging by the open pull request at https://github.com/openwrt/openwrt/pull … 5585c3d1b, this should work.

b. That's a interesting question. With kernel 4.14, the very latest wifi commit, I can use, is from March 5th. There is a patch that work to fix an issue with kernel 4.14, but on the 6th yuhhaurlin does a commit that seems to break the patch. If you remove the patch then all seems to go fine. However, after flashing the image wifi will not work.  So, at this point I'm waiting to hear if others are having issues from the daily build and if there is anyone looking to correct the problem.   << Hope that makes sense.

davidc502 wrote:

b. That's a interesting question. With kernel 4.14, the very latest wifi commit, I can use, is from March 5th. There is a patch that work to fix an issue with kernel 4.14, but on the 6th yuhhaurlin does a commit that seems to break the patch. If you remove the patch then all seems to go fine. However, after flashing the image wifi will not work.  So, at this point I'm waiting to hear if others are having issues from the daily build and if there is anyone looking to correct the problem.   << Hope that makes sense.

No issues with just deleting the patch here (running 6b6f9b4 now).

I've had that blank dropbox issue before though. Make clean/dirclean didn't fix it so I just started again from scratch instead of running distclean. I had to do it again a few days ago too, something about the cortexa9 subtarget change I think.

Anyway, I guess this is an option you'd rather avoid with your complicated config... I have no idea how to actually fix it. Good luck

I'd like to test but I've never got around to finding instructions on how to flash the alternative partition?
If anyone has a link to a resource or just instructions it would be much appreciated.

Hi,

antonsamoziv wrote:

I'd like to test but I've never got around to finding instructions on how to flash the alternative partition?
If anyone has a link to a resource or just instructions it would be much appreciated.

Are you using the factory FW or are you already an alternative?

Are you using the factory FW or are you already an alternative?

If you are using the factory, just download an unstable vs that contains the name "factory" in your name, install it by the page of your router, and after the boot will already be running the new FW, in another partition, with the FW of factory recorded in the reserve part.