@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:
All interrupts in R7800 get assigned to CPU core0 by default, so wifi, lan and usb drivers all run in core0. If you are hitting the performance limits due to I/O activity, you might try balancing the IRQs between core0 and core1 with "irqbalance" package. Discussion about that starting from Netgear R7800 exploration (IPQ8065, QCA9984)
You might also test the shortcut-fast-path "fast NAT" engine that should work also for R7800 (as the patch author @dissent1 uses it): Qualcomm Fast Path For LEDE
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?
[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.
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.
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]
If the default is that IGMP snooping is off, then you're probably already having multicast forwarding enabled. But as long as you don't actually use multicast, it doesn't really matter. Could you take a peek in your router, and see what the default is?
Since I'm rather, shall we say inexperienced, in the build system, can I ask how I would go about to apply the driver commit from your repo to my own build environment (based on master)? Can it be downloaded as a patch and then applied, or do I have to use git to cherry pick that commit from your repo. Again, sorry for being dense, but hopefully I'll improve. And @hnyman, if you think these questions are inappropriate in your thread, I apologize.
Yes.
any github commit can be downloaded just by adding ".patch" to the and of it. Download it with wget,curl or ...whatever, then just apply the patch.
Yeah, you should take this kind of generic discussion to the R7800 exploration thread Netgear R7800 exploration (IPQ8065, QCA9984) (if the topic is R7800- or ipq806x-specific), or even better, start a new thread about IGMP snooping.
Two main reasons: this off-topic discussion clutters this topic, and even worse, you don't reach the attention of people who really know about IGMP snooping (as they likely are not interested in my R7800 build).
Ok, thanks. I'll stop polluting your thread. As you know, I did start a new thread about this issue, but I guess the people that really could answer is too busy to do so.
May I ask one more dumb question, but this one is related to your build environment:
I have used your script to recreate your build environment, and then made some minor customizations for myself (basically just creating my own .config.init-file with my preferred packages). I can then update and make as new commits are made, but if you make changes to your patches, and I want to stay current with those, how would I do that? Is the easiest method to just start over from scratch? Reversing the original patches and then reapplying the new ones is perhaps not a good idea?
Maybe a good starting point is to store and compare the patch files that I publish along my build. Then you can make a diff of the old and new patches and see if anything has changed between the releases. I tweak the code pretty seldom, so usually there are no changes. If you spot changes, it is a question of the easiest method to apply them.
E.g. an one-line change to some script, might be easiest to edit by hand.
Also added new files / scripts are rather easy to spot and apply.
But a more complex change may require more work. If you have not touched the same files, reverting the original patches and applying the new ones may be viable.
If you have edited the same files, in a complex way, it may easiest to start over, and then first apply my new patches and then repeat your own editing.
If you can make diff patch out of your own changes, that will ease the updating.