I tried setting the 5 GHz radio back to AC mode, and download speed was a even slower (less than 20 Mbps), and when Speedtest tried to start upload, the driver got an issue:
Wed Aug 2 21:42:16 2017 kern.warn kernel: [ 1333.739946] ath10k_pci 0000:01:00.0: rx ring became corrupted: -5
@hnyman Is there any point in trying to build from your stable release instead? You apply patches to wifi there too, so perhaps there's no reason to expect different results?
[quote="mroek, post:332, topic:316"]
Is there any point in trying to build from your stable release instead? You apply patches to wifi there too, so perhaps there's no reason to expect different results?
[/quote]The ath10k wifi driver itself is different in 17.01, so the result may be different.
Somewhat similar was seen in May by one user: Build for Netgear R7800
It is possible that ath10k changes done to master in March (smaller buffers) may cause performance degradation, but there has not been really serious discussion about that. dissent1 made a patch to revert those buffer changes, so you might also test that: Build for Netgear R7800
Ok, thanks. I'll just have to read up on applying the patch, I'll admit to being a newbie there. And also, if the wifi driver in 17.01 is different, then it could be interesting to try a 17.01 build too.
I didn't try the patch (at least not yet), instead I built a new firmware based on 17.01 (again using your build environment and patches, just adding and removing some packages for my needs).
The good news is that the 5GHz radio works almost infinitely better. I've set it back to AC mode, and with Speedtest on my phone, I can fully saturate my connection, getting around 300 Mbps both up and down on wireless.
As I told you ... with the 17.01 you will be surprised!
@steom
some ideas for you, if you are still trying to use the master... I guess that you are reaching the performance limit somehow. Might be due to driver interrupt activity choking the CPU. (And the reason may well be wifi performance limitations made to master in March, but which limits are not in 17.01.) You might monitor CPU load with "top" while you have video problems. Likely SIRQ load is at 100%.
Some ideas that might mitigate the problem:
Great firmware, I still love using it.
Can someone tell me if MU-MIMO is supported?
Don't think MU-MIMO is supported, as it's not finished in the mainline linux wifi stack AFAIK.
You're not really losing anything though, unless you have 2 or more MU-MIMO capable devices connecting to your router.
Hnyman, I've tried latest stable firmware, and mtu jumbo frames works fine, by changing mtu on eth0 to 1508, but on your build ( I prefer your build) it still won't work
shows mtu as 1492 when tested. Also I've been getting latency spikes on PS4 with bf1, have it wired into router, using cake qos, any ideas? Router is not under load when ping spikes.
[quote="choppyc, post:340, topic:316"]
I've tried latest stable firmware, and mtu jumbo frames works fine, by changing mtu on eth0 to 1508, but on your build ( I prefer your build) it still won't work shows mtu as 1492 when tested.
[/quote]You mean that it works with release 17.01.2 but not with my master build, right?
17.01 branch is too far away to compare easily. There have been lots of changes since then. (Or did you mean my 17.01 build?)
My build has no build-specific items for switch driver code or config. So, I suspect that it is something more generic. You should check if the buildbot snapshot works for you with the same config (if you are talking about master).
But, I tried setting MTU to >1500 myself in master, and did not succeed. So, I guess that the symptom is real. (I have normally 1500 as the MTU, set automatically)
@hnyman: I'm pretty sure this has nothing to do with your build environment, but did you see my thread on IGMP snooping on this router? The switch seems to be dropping IGMP queries, but not other IGMP (or multicast) packets whenever IGMP snooping is enabled in the switch itself. Do you have any ideas on that one? Can you reproduce it on your router?
You may want to try this driver and check how igmp snooping works https://github.com/dissent1/r7800/commit/fd065e652c2d49db3fab42f800ff9002ce4993fa
You will have to unbridge eth0 and eth1 after this. You'll have lan1-4 and wan interfaces that correspond to relative physical port.
[quote="mroek, post:342, topic:316"]
did you see my thread on IGMP snooping on this router? The switch seems to be dropping IGMP queries, but not other IGMP (or multicast) packets whenever IGMP snooping is enabled in the switch itself. Do you have any ideas on that one?
[/quote]I saw that but did not comment, because I have nothing to say that would contribute. Not my specialty. You should get @blogic @dissent1 @mkresin (or somebody else who is really looking deeper into ipq806x) interested in the issue.
@dissent1: That's very interesting, but I'll have to admit I'm not sure how to get that into my build. Does the LuCI switch setup page still work with that driver? Not really a big deal, but more convenient.
And also, I'm using the 17.01 stable branch and not master (wifi is useless in master for me), which I guess is also troublesome.
Is your version 17.01 also including the patches of the official stable 17.01.2 and meant to be the daily driver?
I only used master so far and want a stable base. What should I go with?
No, it's a different conception, you don't need swconfig to configure the switch, you are getting native Linux tools instead. Each port is represented in kernel as a seperate interface, so you can do whatever kernel allows you to do with it.
Nope, only k4.9+
[quote="dissent1, post:347, topic:316, full:true"]
No, it's a different conception, you don't need swconfig to configure the switch, you are getting native Linux tools instead. Each port is represented in kernel as a seperate interface, so you can do whatever kernel allows you to do with it.[/quote]
Ok. But I guess that if master will be switching over to this new driver, there will need to be LuCI support for configuring it (VLANs and such). With the current state of affairs, I guess there isn't support in base UCI either? So any config needs to be manually scripted for now?
Did you test this yourself? Have you made a build which includes this new driver?
No need for that, it's native Linux tools - you just add interface with '.vlannumber' in luci as usual i.e. lan1.30 - it's lan port 1 tagged with 30 [quote="mroek, post:348, topic:316"]
Did you test this yourself? Have you made a build which includes this new driver?
[/quote]
Yep I'm running it for a pretty while
Ok, thanks. Sorry for being dense here, but to enable IGMP snooping on the switch, would you use sysctl for that, then?
In theory yes, but I don't need multicast to be forwarded, so I have not tested it myself.