Hmm - been doing some performance digging, and a couple of things popped up...
Working on snapshot - at present, this is more like a SBC, in that we have cpu_scaling, and the base core freq is 864000, which steps to 1056000, and then finally up to the spec'ed 1200000 - vast majority of the time it's on the slower clocks...
to check...
cat /sys/bus/cpu/devices/cpu0/cpufreq/cpuinfo_cur_freq
At present, SNAPSHOT boots the CPU at 799999 which gets reset to 864000 - need to dig into this and see if we can address this somehow
The current default scheduling governor is schedutil - this is a fine one for applications, but for a router - performance would be the better choice, and it's available...
As we load up the device - all processes/threads are being routed over to CPU0 - so CPU's 1, 2, and 3 are pretty much idle...
Interrupts are odd - there are some that are scheduled across cores, much most are scheduled on GIC-0 - not a bad thing usually, as this is a GICv2 device, as normally GIC collects and distributes hard IRQ's across the cores (it just looks like everything is on one core, but this is how the driver presents itself to userland).
What's telling though is that items that tweak IRQ's - e.g. IRQBALANCE and the Receive Packet Steering Scripts have zero impact here - it's as though they don't apply at all... looking at the scripts there, I think it just exits...
Flow Offloads - SFO actually hurts performance in my setup, increasing latency, and decreasing thruput - oddly enough, toggling HFO is probably not supported, but is no difference compared to SFO
SQM - tried CAKE with both "Piece of Cake" and "Layer Cake" - on ethernet, so Link-Layer adaptation is Ethernet with Overhead set to 44 - it's a safe place to be, and looking at the qdisc's, it's working and putting up the expected values... challenge is that since everything is running on a single core, and that core is running on the slower clock, throughputs there are slow on a gigabit connection - e.g. about 400 Mbit/Sec with SQM enabled, and core0 at 100%
So at the moment with SNAPSHOT - there's not a lot of tweaks - e.g. disable RPS, disable Flow Offloads, disable SQM, don't use IRQBALANCE - and there, it's stable and reasonably good..
Not sure how much we can do with a 1.2GHz CPU, except to keep it hot with getting clock speeds up to rated, and keeping them warm with the governor set to performance - looking to see what can be done around getting GIC to starting moving IRQ's across more cores, as I mentioned above, it's kind of a unicore at the moment...
Other observations - on the AX1800 (and AXT1800), all interfaces for ethernet and wifi AP's are going across the NSS internal chip fabric - and not clear if the NSS UIB32 is appropriately clocked, at the moment, it's almost as though it's not, as even ethernet across the WAN/LAN is slower than expected - e.g. it's challenged to even get to 600Mbit/Sec right now...
Upside - ath11k radios are quite good at range - e.g. 10 meters across three walls, and it's better than expected when running at 25 dBm Tx power on both radios - 2.4 is quite good with g/n/ax (HE20) and 5Ghz with HE80 is better than expected - compared to MT76 on the GL-Inet MT6000, the AX1800 is better at range, and this is all RF and Rate Control - I'm perhaps a bit biased here, as I've done a lot of work on QC-Atheros platforms, but they've generally been better than most on radios... driver quality not withstanding...
All told - at the moment, we have a very stable image for AX/AXT 1800, and perhaps some additional performance with some deep effort...
Kudos again for all that put in the effort to onboard these two devices, and also to GL-Inet for their efforts on the HW - the HW is pretty good..