Hi Notaz, thanks for noting the neon_loop2
I did have it running during my tests, but had simply overwritten the source code and forgot to git add it to the Letux kernel tree.
Hence it was missing in my link to the script.
I have fixed that now so that high-load -n2 runs the latest version.
It drives temperature up even faster, but no immediate crash:
root@letux:~# ./high-load -n2 100% load stress test for 2 cores running ./neon_loop2 Tue Feb 28 08:52:26 UTC 2017 49° 51° 49° 35° 4018mV 1000MHz Tue Feb 28 08:52:26 UTC 2017 49° 51° 49° 35° 3886mV 1500MHz Tue Feb 28 08:52:28 UTC 2017 50° 50° 49° 35° 3825mV 1700MHz Tue Feb 28 08:52:29 UTC 2017 63° 52° 51° 35° 3825mV 1700MHz Tue Feb 28 08:52:31 UTC 2017 78° 63° 62° 35° 3794mV 1700MHz Tue Feb 28 08:52:32 UTC 2017 86° 70° 69° 38° 3805mV 1700MHz Tue Feb 28 08:52:33 UTC 2017 92° 74° 74° 38° 3798mV 1700MHz Tue Feb 28 08:52:35 UTC 2017 96° 79° 79° 38° 3770mV 1700MHz Tue Feb 28 08:52:36 UTC 2017 96° 79° 79° 38° 3764mV 1700MHz Tue Feb 28 08:52:38 UTC 2017 101° 84° 82° 39° 4050mV 250MHz Tue Feb 28 08:52:40 UTC 2017 82° 83° 79° 39° 4012mV 750MHz Tue Feb 28 08:52:42 UTC 2017 75° 75° 73° 39° 3797mV 1700MHz Tue Feb 28 08:52:43 UTC 2017 75° 75° 74° 38° 3777mV 1700MHz Tue Feb 28 08:52:45 UTC 2017 91° 75° 74° 38° 3759mV 1700MHz Tue Feb 28 08:52:46 UTC 2017 99° 83° 81° 38° 3752mV 1700MHz Tue Feb 28 08:52:48 UTC 2017 104° 87° 85° 38° 4012mV 500MHz Tue Feb 28 08:52:49 UTC 2017 110° 92° 89° 37° 4030mV 500MHz Tue Feb 28 08:52:51 UTC 2017 87° 88° 84° 37° 3789mV 1700MHz Tue Feb 28 08:52:53 UTC 2017 79° 82° 77° 37° 3778mV 1700MHz ^Ckill 4831 4832
root@letux:~#
Well, I might have stopped early enough before it reaches the 125°C hard limit.
To me it looks as if the governor is too slow to react or it is re-enabling the highest clock frequency too early so that there is a lot of overshoot due to heat which has to travel first from the ARM/NEON core to the temperature measurement point. I.e. reducing clock to 500MHz does not cool down fast enough.
The good news is that we are only thermally limited now but no longer from switching noise.
There is still an area for optimization: it may be possible to reduce the OPP voltage at 1.7GHz to reduce heat generation and power consumption.
BTW: is it possible to define all OPPs in DT but stop the default on-demand governor to use higher clock rates until enabled somehow? So far it looks to me as if it really uses uses all OPPs defined in DT.
The problem is that even a simple apt-get update/upgrade or longer install might drive the CPU into 1.7GHz operation and potentially overheat.
In my ideal world, we would still define all OPPs up to 1.5/1.7 GHz in DT but set a limit of 1GHz unless someone overwrites the limit by some tool.
BR, Nikolaus