This is strange, on the CAX1800 this works like a charm:
&qpic_nand {
status = "okay";
nand@0 {
reg = <0>;
nand-ecc-strength = <4>;
nand-ecc-step-size = <512>;
nand-bus-width = <8>;
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "rootfs";
reg = <0x0000000 0x3400000>;
};
};
};
};
@dchard Threaded NAPI really looks to be working, it spreads out the load over 3-4 cores, one still gets hammered more but it doesn't cross 50% or so.
And the peak speed I got on my phone was 724Mbit compared to 552Mbit without threaded NAPI as without it single core gets hammered completely.
I've tested the threaded napi patch for ath11k, works fine so far.
ath11k is now using 1+n napi threads
EDIT: ah, you already did the same 
Yes that looks pretty good.
Will add it probably today after I play some more with fixed partitions and that insanity.
I just wish that NSS-DP had separate TX and RX queues so that load can be split
If possible include qca-ssdk-shell in your build, some of us need to run this script (until nss bridge-mgr works again):
If not possible, no problem, we can build with it.
Thanks
EDIT: Since /usr/sbin/ssdk_sh is a utility and I already built it once, I realized I could just copy it to the same path, if robimarko builds don't include it. Saving the time to build it all.
Sounds great. Let me know when you pushed it, so I can start the build 
Sure, its gonna be late today, gotta watch football as its a home match
@dchard Would it be possible for you to provide me with your config so I can compare it with mine to possibly figure out why my download speed is so bad? I may have overlooked something.
Besides what I described earlier, the rest is all on default. First you need to check the CPU load (per core) on the router during speedtest to see if there is a CPU bottleneck (I use htop to do this). If that is not the case, then it will be your PC or your provider. It is really easy to check this.
Ok. I used htop to monitor the CPU Load.
When running a speedtest CPU 0 goes up to 60%, CPU 1,2,3 are less than 1% during the test.
Yep, that is the expected behavior.
Did some further speedtests, saw CPU0 up to 80% - bottleneck?
Does the workload look similar on your device?
This is 920Mbits DL with PPPoE. I would assume on pure IP this would even be lower by 10-20%.
If you have packet steering enabled, and SW offload enabled, plus the IRQ mods I posted, that is my config exactly.
Oh man, thanks!
i activated SW offloading (Network > Firewall > General Settings > Routing/NAT Offloading) and it moves in the right direction. 720 Mbits DL.
How can i check if packet steering is enabled?
EDIT:
Packet steering is now enabled, however 720Mbits DL is currently the max i can reach.
And me trying to understand why jumping from one router to the other took like 5 minutes for being able to get the DHCP ACK. This is why 
With the script it's instantaneous again.
If the original script gives trouble, try this version from Edrikk here:
If you are not reaching 90+% on a single CPU core, the limitations is somewhere else. Maybe your provider is not able to keep up in busy hours. It can be crappy anti virus, or firewalling issues, bad cabling etc. All off topic here. Maybe you can try again when Robi merges the NAPI patches.
Wait a minute: you are trying on direct cable connection and not on wifi, do you?
Thank you, thank you, thank you, thank you, thank you, thank you!
I was banging my head and my phone because of this! Of all my house devices including other phones equal to mine, only mine was loosing connection after a couple of minutes in standby and even worse when I moved a bit far away from the router. And I was thinking the reason had something to do with my phone being the only one using a wireguard VPN while the router was also serving VPN to some devices (not mine).
You pointed me in the right direction, but now I have some data to add that may help development, I hope.
Build yesterday with "nss-firmware-ipq8074", "kmod-qca-nss-dp" and "qca-ssdk-shell", also user @dchard IRQ optimizations, but in my hurry forgot to add the wifi_transition_workaround.sh!
I am trying to note here that even without the script, my connectivity issues were fixed. Before this I missing nss-firmware-ipq8074 (and qca-ssdk-shell), I suppose this firmware package could be set to yes by default?
I'd love to take the credit, but the script is fully thanks to @joba-1 per his post here. I just packaged it so that it can be easily put in the startup and sent to the background.
The scripts are identical. i.e. they both depend on qca-ssdk-shell. The script keeps an eye on the rolling log file and if the substring "AP-STA" is seen calls a utility (from qca-ssdk-shell) to to a flush.
Went through to code to find out what could have happened but I'm not sure if it's the kernel messing up or uboot. Basically uboot will write the fdt into memory and pass its location to the kernel in the r2 register. If kernel was compiled with fdt support, it will load the fdt from there and unflatten it to build its internal tree representation.
I can think of 2 ways you could debug this further. Either add some logging to where the kernel unflattens the fdt to see if the nodes actually reach the kernel or inspect the fdt in uboot with the fdt command. After all it might be uboot that deletes the partition nodes from the fdt for some Xiaomi-ish reason.