Now the ath10k-ct-firmware package is separate from the mainline ath10k-firmware package, so the version number can reflect the ath10k-ct-firmware date. Now it is "2020-04-24-2"
Nothing special really.
I have lately tested modifying the cpufreq-ondemand with a bit milder ramp-up trigger level (60%) than the 35% discussed in some forum threads. The Linux default 95% is very high and practically means that the router needs to be fully utilised before the CPU is ramped up.
From the bursty network traffic perspective, the samplingdown period is maybe even more important , so that the CPU frequency does not decrease too quickly before the next burst.
The Linux defaults are global across the CPUs, so the 95% and samplingdown is probably originally been thought from desktop computing perspective, where the CPU load remains more stable without being quite so bursty.
I have also been looking at the cake stats and testing network speed, and have noticed that sometimes cake gets stuck to mode where the latency remains at some 50-60 ms instead of my normal 20 ms under load. I have been wondering if that is somehow related to either CPU frequency changes and/or irqbalance stuff, so that cake initially calculates some parameter wrong and then gets stuck to it.
Two consecutive runs with irqbalance enabled:
Second run, where latency gets stuck to 60 ms:
Ps. In general I get the same or better throughput and lower latency with simple/fq_codel than with cake, so I prefer fq_codel. It suits to my connectivity.
With fq_codel limits set to 190 Mbit / 18 Mbit, the flent speedtest realises 180 Mbit download and 16 Mbit upload with 18.5 ms latency. Good enough for me.
FWIW, I like to keep mine at 800MHz min freq, I noticed that it constantly flip-flops 384-600-800 anyway and the temperature increase is not noticeable, maybe 1-2C. That seems to also make it more stable, without it I seem to get some random reboots, though that may be just pure coincidence, not scientific evidence.
(I have started with a 9.6 kbit modem in the early 90s, then 28.8 and later 56 kbit, then later cable 10/1 Mbit, then cable 90/12, so the current 180/16 Mbit with 18 ms latency to another country under heavy load is good enough So I haven't tweaked for the last bit of speed.)
No need to change then. But just to elaborate for a fixed packet size you can easily make up for under-accounting the per-packet-overhead, by just setting the shaper-rate a tad lower (and vice versa you can counter too high a shaper rate with increased per-packet-overhead), but the very moment you add packets of different sizes to the mix (like voip packets that are often in the 200-300 Bytes range) things can get out off whack. By which I mean, the same shaper-rate/overhead combination that works great to control bufferblat for large packets can start to fail keeping too much data out of the under-managed and over-sized buffers of the network element that you want to take out of the latency equation with your shaper.
Tl;dr: Specifying per-packet-overhead >= the true per-packet-overhead does not help in getting more speed, but rather allows reliable bufferbloat control independent of the actual packet size distribution on the link.
That said, if it works, it works, and you set the policy of your network; I just wanted to add some rationale why one might want to fiddle with the overhead accounting.
Wondering if on this build, or openwrt in general on the r7800 supports eSATA port multiplier. I have a Port Multiplier aware enclosure, setting up an SMB service on the r7800.
according to dmesg:
[ 5.266546] ahci 29000000.sata: flags: ncq sntf pm led clo only pmp pio slum part ccc apst
the "pmp" flag i'm assuming is port multiplier, so i am assuming it is supported in the driver? I have tried multipler eSATA enclosures and only one drive is recognized, both on this build and snapshot.
on some other devices, as the WRT32X, it's an option in the kernel config, CONFIG_SATA_PMP=y , is this an option for the @hnyman build for our device?
thought I would ask to see if anyone else has run into this issue or had any thoughts! Thanks!
~# opkg update
Downloading http://downloads.openwrt.org/releases/19.07-SNAPSHOT/targets/ipq806x/generic/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_core
Downloading http://downloads.openwrt.org/releases/19.07-SNAPSHOT/targets/ipq806x/generic/packages/Packages.sig
Failed to decode signature
Signature check failed.
Remove wrong Signature file.
Downloading http://downloads.openwrt.org/releases/19.07-SNAPSHOT/packages/arm_cortex-a15_neon-vfpv4/base/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_base
Downloading http://downloads.openwrt.org/releases/19.07-SNAPSHOT/packages/arm_cortex-a15_neon-vfpv4/base/Packages.sig
Failed to decode signature
Signature check failed.
Remove wrong Signature file.
Downloading http://downloads.openwrt.org/releases/19.07-SNAPSHOT/packages/arm_cortex-a15_neon-vfpv4/luci/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_luci
Downloading http://downloads.openwrt.org/releases/19.07-SNAPSHOT/packages/arm_cortex-a15_neon-vfpv4/luci/Packages.sig
Failed to decode signature
Signature check failed.
Remove wrong Signature file.
Downloading http://downloads.openwrt.org/releases/19.07-SNAPSHOT/packages/arm_cortex-a15_neon-vfpv4/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_packages
Downloading http://downloads.openwrt.org/releases/19.07-SNAPSHOT/packages/arm_cortex-a15_neon-vfpv4/packages/Packages.sig
Failed to decode signature
Signature check failed.
Remove wrong Signature file.
Downloading http://downloads.openwrt.org/releases/19.07-SNAPSHOT/packages/arm_cortex-a15_neon-vfpv4/routing/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_routing
Downloading http://downloads.openwrt.org/releases/19.07-SNAPSHOT/packages/arm_cortex-a15_neon-vfpv4/routing/Packages.sig
Failed to decode signature
Signature check failed.
Remove wrong Signature file.
Downloading http://downloads.openwrt.org/releases/19.07-SNAPSHOT/packages/arm_cortex-a15_neon-vfpv4/telephony/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_telephony
Downloading http://downloads.openwrt.org/releases/19.07-SNAPSHOT/packages/arm_cortex-a15_neon-vfpv4/telephony/Packages.sig
Failed to decode signature
Signature check failed.
Remove wrong Signature file.
~Unable to do opkg update not sure what's the issue here~
nvm... I did another reset that seems to have fixed the error
Is there much performance difference between the 19.07 stable build and the snapshot builds? I assume most performance patches/tweaks are done to both, but how much difference is the new 5.4 kernel making to performance?
Not much difference, I think.
Both are good enough for "normal use".
And generally, the new kernels have actually caused performance degradation, as new functionality and complexity is usually being added. E.g. kernel 4.4 a few years ago was much slower than 4.1 for many routers...
Read e.g.
So I haven't tweaked for the last bit of speed.)