Haha, no problem 
You're doing an amazing job. Compile has started again I will report back here as soon as I've flashed it.
What @Mushoz said and I would like to add that your work has been invaluable to the OpenWRT and LEDE community!
Did this change anything about 2.4ghz performance? I was busy running the tests on the previous commit: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=a186c2ab70d3980d3da502da7e08fb3644104815
When I noticed your comment that you needed an additional check, so I stopped my testing and flashed a new build that included the latest commit: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=1f427bd6166afa2aa11384fa559be9459397a0fe
However, unless something changed in the RF inference, the previous commit actually performed better. 145 mbit versus 95 mbit, both on channel 11 with a channel width of 40mhz. I don't have a screenshot of these previous results, since I stopped testing the moment you posted that comment. However, the speed has been saved in the previous results section in dslreports, so hence my comparison.
Case in point though, is that with the latest commit performance for me personally is still way below what it was before the Minstrel patches.
Performance is back up with your latest commit but it is a bit weird. These numbers are the end result of my simple test on the 5 GHz band (laptop client connecting to iperf3 on router, letting it run for 60 seconds) and are a bit all over the place: 51.1, 84.1, 98.4, 97.8 and 65.4 Mbits/sec. If I look at my results on a second by second basis it seems that sometimes the transfer dips (ie from 100 to 50 Mbits/sec) or even chokes (0.00 Mbits/sec) but then it ramps up again to normal speeds.
Performance on 5ghz is amazing for me. Did you try the very latest commit? It was a last minute fix. Getting 525 mbit upload from my Phone via iperf3 (Wow!, amazing job @nbd) and a little bit over 300mbit download (if this could be brought up to the same standards as the upload that would be amazing 
). Haven't really tested other commits on 5ghz performance so I don't have any comparisons. But I am not seeing any wild dips during the test. Just normal fluctuations.
Yup, my build includes that commit. Keep in mind that I am running iperf3 whereas you are running the dslreports speedtest. Even though, my results are kinda weird so, I am redoing my build env.
5ghz performance was held back by WAN speeds (or more accurately, the CPU couldn't keep up with PPPoE, NAT, firewalling and the WiFi load all at the same time). So the 5ghz tests were done with iperf3 with a computer connected via gigabit LAN as the iperf3 server.
Verified my dslreports speedtests with iperf3 as well. I am getting similar results (around 100 mbit download) through 2.4ghz.
Wow, huge performance discrepancy then. Just redid my build env. so compiling once again.
Probably a dumb question but when doing dslreport speedtest over 5 GHz, is the CPU pegged at 4.0? Have you tried messing around with IRQ affinities?
Try this
@nbd @Bartvz A completely unrelated observation: Why is it that I require multiple dslreports.com upload streams in order to get the maximum performance over 2.4ghz?
Testing with iperf3 shows me 45 mbit upload with 1 stream (via dslreports and iperf3), but 8 streams give me ~100 mbit upload.
5ghz actually performs best with just 1 stream, although that might be because multiple streams is probably overloading the device (it's a phone). That 500+ mbit result was with a single upload stream over iperf3.
Is this a wifi n only phenomenon? Or is this simply caused by the 2.4ghz client? Download speeds are slightly better as well with 8 streams (115 mbit) vs 1 stream (95 mbit), but the difference isn't nearly as big.
Not yet. All the IRQs are hitting CPU0, so there definitely some optimization that can be done. CPU idle is way above 0% in either case. But that's something that I will look into once this bug has been fixed and I'm running a build that won't be upgraded on short notice (Although knowing me, I will probably flash again just because I like tinkering and trying out new stuff xD).
The code shows the following line:
set_irq_affinity mt7603e 2
This will have to edited to match the DIR-860, which is using the mt7602e chip IIRC. There's actually two lines in the interrupts table with that name (as the 5ghz wifi shares a similar name), so the script will also have to work around that issue. Here's the relevant output:
root@LEDE:~# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
8: 324639 324618 324611 324586 MIPS GIC Local 1 timer
9: 10330 0 0 0 MIPS GIC 63 IPI call
10: 0 551691 0 0 MIPS GIC 64 IPI call
11: 0 0 665614 0 MIPS GIC 65 IPI call
12: 0 0 0 703472 MIPS GIC 66 IPI call
13: 22981 0 0 0 MIPS GIC 67 IPI resched
14: 0 80024 0 0 MIPS GIC 68 IPI resched
15: 0 0 3770776 0 MIPS GIC 69 IPI resched
16: 0 0 0 49967 MIPS GIC 70 IPI resched
18: 14 0 0 0 MIPS GIC 33 serial
19: 0 0 0 0 MIPS GIC 29 xhci-hcd:usb1
20: 2418149 0 0 0 MIPS GIC 10 1e100000.ethernet
21: 7 0 0 0 MIPS GIC 30 gsw
22: 498445 0 0 0 MIPS GIC 11 mt76x2e
23: 1997795 0 0 0 MIPS GIC 31 mt76x2e
So make it this way
set_irq_affinity 1e100000.ethernet 2
set_irq_affinity xhci-hcd:usb1 4
set_irq_affinity mt76x2e 8
The grep in the set_irq_affinity function will then return two different lines for mt76x2e, wouldn't it? The irq identified with 22 in above table, and the one identified with 23 in above table. Might be easier to simply move them around manually
Nope, the first 1, there's -m 1 parameter
Thank you. Not very familiar with all the grep switches. And thank you for the script! I'll try it out as soon as I'm on a build that will be up and running for a while
@dissent1 thanks for the script, hat will be useful! What you are proposing is putting both wireless cards on CPU3 which should also work. But there probably is a way to next to looking at the name of the interrupt to also look at the corresponding IRQ number and use them both to group them. Also, wouldn't it be advisable to put the IRQ's on multiple cpu's if more cpu power is needed? Did you do some benchmarking?
@nbd, with a redone build env. with the latest of your patches and setting my 5 GHz to another channel, my 5 GHz throughput seems restored (~110 Mbits/sec). However, it seems that the 5 GHz band performance is more sensitive for interference. When there is another network with a weak signal (-85 dBm) on the same channel the throughput drops to the levels reported earlier.
Not really, with my proposal first mt76x2e will be put onto cpu3, the second mt76x2e will remain intact - that's on cpu0. So with that code all interrupts are going to be effectively spread among all cores/threads. I suppose 2nd mt76x2e is 2.4ghz band card so it will share the 1st core (cpu0 and cpu1) with ethernet
@sotux how is your 2.4ghz performance with the latest patches applied? Are you also still seeing a regression compared to before all the Minstrel patches?
After applied the latest commits, the 2.4G & 5G wifi speed is normal. Thanks @nbd.
| Band(GHz) | Download Speed | Upload Speed |
|---|---|---|
| 2.4 | 45.8 Mbits/sec | 74.7 Mbits/sec |
| 5 | 53.9 Mbits/sec | 90.5 Mbits/sec |