I compiled also a 4.14 version without CPU frequency scaling, and that naturally works ok.
With the frequency scaling patch, the router's clock seems to lag by some 40-50%, which is quite much and clearly indicates that something is calculated wrongly (and/or does not get adjusted along the CPU frequency and the real-time clock ticks at half-pace 933MHz while it is read like it would be running at full 1866 MHz speed).
Comparing the kernel bootlogs of 4.9 and 4.14 reveals that there is something different in clock handling. Apparently some things have moved from 32bit to 64bit and clock resolution dropped from 40ns to 1ns?
kernel 4.9:
[ 0.000000] Switching to timer-based delay loop, resolution 40ns
[ 0.000003] sched_clock: 32 bits at 25MHz, resolution 40ns, wraps every 85899345900ns
[ 0.000008] clocksource: armada_370_xp_clocksource: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 76450417870 ns
[ 0.000113] Calibrating local timer... 933.19MHz.
[ 0.060030] Calibrating delay loop (skipped), value calculated using timer frequency.. 50.00 BogoMIPS (lpj=250000)
Not sure how that affects the CPU frequency scaling, but is likely part of the challenge. And just highlights why it would be great to have the frequency scaling functionality upstreamed in Linux itself.
It is also possible that something relevant has changed in the kernel config and/or devicetree files.
I have no large motivation into looking to fix the things right now, as I am not really a clock specialist (and mvebu is not my main router). I will leave the patches there in case somebody wants to experiment further.
for me the frequency driver was a nice to have; but as it wasn't fully developed, incorperating cpu-idle and various power tables, it didn't do much towards power consumption. Therefor we can easily live without it. Again your efforts are much appreciated.
It's a pity there is no 802.11AC device that is fully working though. the WRT devices have this issue, the netgear devices keep having errors in the logs on the wifi connections. Am still hoping that there will be a "perfect" device eventually.
@hnyman Reverting those commits and disabling those config symbols restores the k4.9 timer state, so it probably fixes your time issue when using freq scaling patchset.
Thanks for the suggestion. Seems that reverting those config symbols is enough to make the clock behave again with the cpufreq driver. (The changes done to master today were not enough)
Yes.
I haven't yet updates the commit in this thread, so it creates six patches 801-806, but after the most recent kernel 4.14. version bump, the patch 805 needs to be deleted.
I will update this commits here sooner or later, but the previous message was just a heads up that 805 is unnecessary.
I'm wondering if the chipsets / driver blobs in the Linksys WRTs just don't have any available/enabled power saving options? I took a few readings on my 1900ACS with the stock firmware and it seems to make no difference if it's been idling for 1 second or 10 minutes or if one or both of the radios are turned off... it idles at 8 watts. This is the same power consumption I see at idle under OpenWRT... so it's not any worse, just surprising that you can't move the needle on it. (I've never seen a system where you can cut the clock rate in half and/or turn off wireless radios and not see some reduction)
If I remember correctly, the power save cpuidle mode is disabled, as it does not work in 38x. That was the reason for "wrt1900ac v1 crashes" 1-2 years ago, as it was not yet disabled for 370 (where it failed, too).
* Currently the CPU idle support for Armada 38x is broken, as
* the CPU hotplug uses some of the CPU idle functions it is
* broken too, so let's disable it
I noticed pretty much the same (based on CPU temps, like discussed above), so I have not pushed this to be included in the Openwrt sources. Apparently the benefit is rather minimal.
What i’ve read is that the hardware itself apparently is broken and that is why the code for it was abandoned. The chips refused to come out of powersave or something similar. Has been a few years, so can’t recollect the fine details anymore.
Actually works quite good on wrt1200.
Frequency switching isn't lagging at all.
Thank you for this =)
But it could stay longer in the max frequency.
i tried to play around with up_threshold and set it to 25 (Yes that low) works a bit better.
And maybe also change sampling_down_factor to some way higher value so the cpu stays a bit longer in the higher clock.