Ok, thanks. I think I got it. I'll play around a little with it in the near future, but since the wifi is unstable and useless (for me) in master, I'll need to run with stable for daily usage.
the wireless "performance" is ridiculous in master.
not only for you!
I wonder why some people seems to be happy with it, then. For me master is mostly good, except that it seems impossible to use multicast without flooding the wired network with the data.
I wonder why some people seems to be happy with it
Because they only use wireless for WhatsApp and browsing the www from the tablet.
In master, If I do 1 or 2 large file transfers between my NAS and laptop it will crash the 5Ghz band, regular usage doesn't usually cause issues. I suspect it has to do with buffers like hnyman mentioned earlier. It's been this way for a while in terms of master builds.
@dissent1, @nbd, @blogic, @gcobb or anyone else who knows their way in the switch driver, I need some assistance. On the R7800, whenever IGMP snooping is enabled on the switch, all IGMP queries (but not reports) ends up at eth0 (port 0 on the switch chip). This renders multicasting useless, since the queries from the server (which is not in WAN) never reach the clients (which are also not on eth0/WAN). I believe this has to be a bug in the switch configuration. All the details in this thread.
Hi all,
recently I became an owner of new R7800. From the beginning I was annoyed a little by bright leds lighting through the ventilation grill. When you look at router from the top it is ok, but if it on the level of your eyes it very uncomfortable.
So I decided to improve it. Instruction in the beginning of this thread was very helpful, I used a plastic card to prong all the latches.
Also I removed a cover and it revealed weird picture how they used thermopads, it was scruffily with little contact area. Not sure why it is so.
and fingerprint
It is good that I had some thermopads with 1.5mm thickness in my PC stuff so I added it to missed area
I didn't measure temperature before and after but I think this way of cooling is more proper.
Then I took isolation tapes and stick it in front of leds
Result is excellent, lights come only from the top indicators and no excessive bright lights through the ventilation grill
And then I installed LEDE Reboot SNAPSHOT r4675-e5e6045130 
I found wireless performance is good.
What is not so good, but I hope it will be sorted out
- ping to the provider on my ancient Asus RT-AC66U router was 7-8 ms, now on R7800 LEDE it is 8-10 ms
- usb3 is very slow comparing to Voxel f/w
what is the issue with wireless performance, is it LEDE related or with all open source?
Before I swtiched to LEDE I measured wire, wireless and usb performance on latest Voxel V1.0.2.33SF f/w
Then I compared it with LEDE and at least wireless is even better on LEDE.
On Voxel on 5G I had 53Mb/s upload and 64Mb/s download (speed is measured by copying of files with size 3-5 Gb)
Now on LEDE it is 64Mb/s upload and 66Mb/s download, i e nearly 520Mbit. Isn't it is good result?
On the LEDE Reboot SNAPSHOT r4675-e5e6045130 I didn't face an issue, what large files do you transfer?
I created file with 45Gb (45891Mb) and downloaded it in 11 min 52 sec with no any crashes, i e it is 64Mb/s or 515Mbit
actually only in master.
the Stable Release builds is fine.
ok, got it
Is this 520 Mbit the best speed on 5G that can be achieved or it may be even better? (on any firmware)
I have a question regarding a performance issue I am seeing, but which I don't know how to investigate.
In my setup I have a regular WAN connection for internet traffic, which provides 300/300 Mbit/s. In addition I have an IPTV connection on a different physical interface. Usually the STB will be connected directly to this interface, where it receives an IP from a DCHP server, and then uses IGMP to subscribe to the TV channels. However, I want to move the STB to my LAN instead (for good reason, but I'm trying to keep this post short(ish)), so I am using a VLAN capable switch to provide a connection from the IPTV interface to the router. This VLAN is then received at one of the switch ports on the router, and for all intents and purposes acts like a WAN dedicated for IPTV.
The STB gets an IP (in my LAN) from the router, and I've set up appropriate forwardings and routes to make this work. However, there is an issue with performance, because when I load the WAN connection with Speedtest, there is some stuttering on the TV, indicating that the multicast stream is being disturbed,
The TV multicast is probably somewhere around 5-10 Mbit/s, while the WAN is around 300 Mbit/s, and the hardware should be more than capable to handle this without any issues. Now, for the IPTV eth0 isn't involved at all, but for the internet both eth1 and eth0 are involved. The computer and the STB are both in the LAN, but the Speedtest is obviously using eth0 for internet connectivity.
If I copy some large files between a NAS and my computer (both in LAN) I see no issues, but that's (I guess) because it isn't a routed connection (the switch handles that in hardware). However, in the first test, both connections are routed, so obviously loads the CPU. How do I investigate this to find out where the bottleneck is?
I've tested irqbalance, and it does balance out the irqs quite nicely, and possibly lessens the issue somewhat, but not nearly enough.
Try this to see if it's a cpu issue
Ok, I'll try that! That should work also for stable, right? Just yet another newbie question: I will need to manually download first the initial commit as a patch, and then the four additional commits mentioned in the comments? And then manually copy kernel patches since I'm on stable?
No, it's a complete commit. You just need to copy patches if you are on stable 17.01.
Ok, I download it as a patch:
https://patch-diff.githubusercontent.com/raw/lede-project/source/pull/1269.patch
However, it doesn't apply because of the different kernel version, so it asks which file to patch:
@debianx64:~/OwrtLEDE-stable/lede1701$ patch --dry-run -p 1 -i 1269.patch
checking file package/kernel/shortcut-fe/Makefile
checking file package/kernel/shortcut-fe/src/Kconfig
checking file package/kernel/shortcut-fe/src/Makefile
checking file package/kernel/shortcut-fe/src/README
checking file package/kernel/shortcut-fe/src/fast-classifier.c
checking file package/kernel/shortcut-fe/src/fast-classifier.h
checking file package/kernel/shortcut-fe/src/nl_classifier_test.c
checking file package/kernel/shortcut-fe/src/sfe.h
checking file package/kernel/shortcut-fe/src/sfe_backport.h
checking file package/kernel/shortcut-fe/src/sfe_cm.c
checking file package/kernel/shortcut-fe/src/sfe_cm.h
checking file package/kernel/shortcut-fe/src/sfe_ipv4.c
checking file package/kernel/shortcut-fe/src/sfe_ipv6.c
checking file package/kernel/shortcut-fe/src/userspace_example.c
checking file target/linux/generic/config-4.4
Hunk #1 succeeded at 2670 (offset -12 lines).
Hunk #2 succeeded at 3638 (offset -13 lines).
can't find file to patch at input line 11298
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/target/linux/generic/config-4.9 b/target/linux/generic/config-4.9
|index 24bbbc05878..1b1df923ee3 100644
|--- a/target/linux/generic/config-4.9
|+++ b/target/linux/generic/config-4.9
--------------------------
File to patch: ./target/linux/generic/config-4.4
checking file ./target/linux/generic/config-4.4
Hunk #1 succeeded at 2670 (offset -281 lines).
Hunk #2 FAILED at 3982.
1 out of 2 hunks FAILED
checking file target/linux/generic/hack-4.4/950-net-patch-linux-kernel-to-support-shortcut-fe.patch
checking file target/linux/generic/hack-4.4/951-bridge-Add-new-bridge-APIs-needed-for-network-HW-acc.patch
checking file target/linux/generic/hack-4.4/952-net-conntrack-events-support-multiple-registrant.patch
checking file target/linux/generic/hack-4.9/950-net-patch-linux-kernel-to-support-shortcut-fe.patch
checking file target/linux/generic/hack-4.9/951-bridge-Add-new-bridge-APIs-needed-for-network-HW-acc.patch
checking file target/linux/generic/hack-4.9/952-net-conntrack-events-support-multiple-registrant.patch
I tried giving it the config-4.4 file, but it doesn't apply cleanly.
The only option is to apply it manually then 
Ok. I'll try. But judging from the output above, am I right in assuming that the only file I will (hopefully) need to manually patch is the config-4.4 file?
Yeah, seems so
Unfortunately, it doesn't compile for me:
/lede1701/build_dir/target-arm_cortex-a15+neon-vfpv4_musl-1.1.16_eabi/linux-ipq806x/shortcut-fe/sfe_ipv4.c:1366:5: error: 'struct sk_buff' has no member named 'fast_forwarded'
Does that look familiar?
Edit: I see that this error is because the patches in hack-4.4 hasn't been applied. I didn't manually copy the patches to the patches-4.4 directory, which I should have. I'll leave this post here anyway, even if it shows my utter lack of understanding... 
Edit2: It doesn't seem to affect my performance issue. If anything, it actually got worse (but that could be just a coincidence, though, as I didn't test much). Ah well, thanks for suggesting it anyway.
@avx @mroek @steom
You might be interested to test reverting the ath10k buffer reduction that was done in March in master. That might help with performance issues.
The background is that the ath10k buffer size reduction was introduced a bit sneakily into ipq806x with a commit improving support for QCA4019. (The commit title talks about QCA4019 but does not mention that ath10k buffers get reduced for all chips):
https://git.lede-project.org/?p=source.git;a=commit;h=cc189c0b7fa015978b04bb663a75b1da726376b5
I tried to initiate discussion about that action later, but that got no traction as there was no real proof that the buffer reduction caused harm in a significant way. If there would be proof, the action might hopefully be retracted.
I have made a R7800 test build from the current master that reverts the ath10k buffer size reductions:
Downloadable from my build's dir:
- revert buffer size: lede-r4694-e7373e489d-20170811-ath10k-buffer-test
- normal : lede-r4694-e7373e489d-20170811
Ps. If anybody wants to try the same in his own master build, it is just about deleting these two patches that were introduced by that commit:
package/kernel/mac80211/patches/960-0010-ath10k-limit-htt-rx-ring-size.patch
package/kernel/mac80211/patches/960-0011-ath10k-limit-pci-buffer-size.patch