Dietpi: Improved NEO settings

[ThomasKaiser]

Just FYI, I did a lot of testing regarding consumption, temperatures and so on and at Armbian we came up with new NEO settings. We come out of u-boot with 480/408 MHz (cpu/DRAM) and limit maximum cpufreq to 912 MHz since this ensures that the SoC will be fed with 1.1V VDD_CPU all the time and also some more heavy tests always ended up in NEO deadlocking when allowing 1200 MHz (on 4 different NEOs I tested with so it's not just one lemon board).

• http://forum.armbian.com/index.php/topic/1728-rfc-default-settings-for-nanopi-neoair/?view=getlastpost
• http://forum.armbian.com/index.php/topic/1748-sbc-consumptionperformance-comparisons/?view=getlastpost

Issue can be closed immediately after taking notice :)

[Fourdee]

@ThomasKaiser

Thanks for letting us know :+1:
Is this active in the .fex yet https://github.com/igorpecovnik/lib/blob/master/config/fex/nanopineo.fex,?

heavy tests always ended up in NEO deadlocking when allowing 1200 MHz (on 4 different NEOs I tested with so it's not just one lemon board).

Doesn't sound good for the board. Hardware limitation/design defect?
Its a shame, I think the NanoPi NEO is a stunning device, yes H3 and not 1GBit ethernet, but its an impressive headless miniature SBC and cheap as chips.

[k-plan]

@ThomasKaiser

thank you very much. Interesting comparison and testing results. 👍
You on the way for a Allwinner H3 guru. 😃

[ThomasKaiser]

Doesn't sound good for the board

Well it's not meant for HPC but for an IoT node or small headless device. I think some design decisions like single bank DRAM configuration or LDO regulators instead of buck converters limit the use cases but hey... it's tiny and when used with the right settings everything is ok.

The above is the correct fex but as already said we use a different u-boot configuration and board/cpufreq config as well.

BTW: _If_ only lightweight stuff runs on the board allowing 1200 MHz is an option (stuff gets done faster, CPU enters low power states earlier). But as soon as heavy workloads have to be considered based on my tests limiting to 912 MHz (1.1V VDD_CPUX) is the better idea.

But feel free to do own tests: sysbench (lightweiht), cpuminer and cpuburn-a7 are all freely available :)

[Fourdee]

@ThomasKaiser

cat << _EOF_ > test
#!/bin/bash
while true
do

echo -e "\$(cat /sys/class/thermal/thermal_zone0/temp)'c | Min \$(( \$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq) / 1000 ))Mhz | Max \$(( \$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq) / 1000 ))Mhz"
sleep 1

done
_EOF_
chmod +x test
./test

sysbench --test=cpu --num-threads=$(nproc --all) run

Looks like thermal throttling is kicking in on mine < 10 seconds in:
Governor = performance

root@DietPi:~# ./test
58'c | Min 240Mhz | Max 1200Mhz
58'c | Min 240Mhz | Max 1200Mhz
58'c | Min 240Mhz | Max 1200Mhz
58'c | Min 240Mhz | Max 1200Mhz
58'c | Min 240Mhz | Max 1200Mhz
57'c | Min 240Mhz | Max 1200Mhz
67'c | Min 240Mhz | Max 1008Mhz
68'c | Min 240Mhz | Max 1008Mhz
69'c | Min 240Mhz | Max 1008Mhz
69'c | Min 240Mhz | Max 1008Mhz
69'c | Min 240Mhz | Max 1008Mhz
67'c | Min 240Mhz | Max 816Mhz
70'c | Min 240Mhz | Max 1008Mhz
68'c | Min 240Mhz | Max 816Mhz
70'c | Min 240Mhz | Max 816Mhz
69'c | Min 240Mhz | Max 1008Mhz
71'c | Min 240Mhz | Max 816Mhz
69'c | Min 240Mhz | Max 1008Mhz
71'c | Min 240Mhz | Max 816Mhz
69'c | Min 240Mhz | Max 1008Mhz
71'c | Min 240Mhz | Max 816Mhz
68'c | Min 240Mhz | Max 816Mhz
72'c | Min 240Mhz | Max 1008Mhz
70'c | Min 240Mhz | Max 816Mhz
68'c | Min 240Mhz | Max 1008Mhz
73'c | Min 240Mhz | Max 816Mhz
69'c | Min 240Mhz | Max 1008Mhz
73'c | Min 240Mhz | Max 816Mhz
71'c | Min 240Mhz | Max 816Mhz
69'c | Min 240Mhz | Max 1008Mhz

[ThomasKaiser]

Looks like thermal throttling is kicking in on mine < 10 seconds in:

To be expected since idle temperature was already just 7°C below first thermal trip point -- please keep in mind that when using mainline u-boot with legacy H3 kernel for whatever reasons thermal readouts are somewhat off, so having some safety headroom is important.

Governor = performance

Well, I hope that's not default? Interactive does a much better job on this kernel and almost immediately switches from lowest to highest clockspeed when necessary. Setting performance on all H3 boards except of BPi M2+ (the worst H3 board available in this regard since always at 1.3V) is a bad idea since then VDD_CPUX is always at the highest level. Check

/sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state

if in doubt about efficiency of interactive :)

[Fourdee]

@ThomasKaiser

Well, I hope that's not default? Interactive does a much better job on this kernel and almost immediately switches from lowest to highest clockspeed when necessary.

Hehe, no we dont use performance by default. The only images I know that do, are the official Odroid Ubuntu images.

ondemand is default on all DietPi images with a 25ms sampling rate (25000) /sys/devices/system/cpu/cpu"$i"/cpufreq/ondemand/sampling_rate and 2 second before down sampling (80) /sys/devices/system/cpu/cpu"$i"/cpufreq/ondemand/sampling_down_factor.

We also set the threshold percent trigger to 50% /sys/devices/system/cpu/cpu"$i"/cpufreq/ondemand/up_threshold

The official RPi image has a default 300ms sampling rate, last time I checked. So 300ms before each tick to check if clocks need increasing.

Personally, I find ondemand great for headless/server stuff, interactive for front end user stuff like desktop/kodi usage.

/sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state

Yep, just for stats, heres my XU4 capped at 1.4Ghz and using ondemand:

root@DietPi-XU4:~# cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
1400000 4839838
1300000 0
1200000 0
1100000 0
1000000 0
900000 0
800000 0
700000 98410
600000 307795
500000 509577
400000 1490632
300000 2668945
200000 76331351

[Fourdee]

@ThomasKaiser

To be expected since idle temperature was already just 7°C below first thermal trip point -- please keep in mind that when using mainline u-boot with legacy H3 kernel for whatever reasons thermal readouts are somewhat off, so having some safety headroom is important.

Curious, if 80'c is the thermal limit, and we get 73'c readout, hows does the kernel know its 80'c, or is thermal throttling controlled by the H3 SoC on a hardware level?

[ThomasKaiser]

Curious, if 80'c is the thermal limit, and we get 73'c readout, hows does the kernel know its 80'c, or is thermal throttling controlled by the H3 SoC on a hardware level?

It's Allwinner's budget_cooling stuff, so it's a driver reading fex settings and taking care of CPU/GPU throttling according to settings (search for ths and cooler in fex file). In short: You define thermal trip points (temperatures) that lead to different states (throttling down or shutting down CPU cores). This mechanism in Allwinner's BSP 3.4.x kernel is the same for H3, A64 and (in case you ever want to support the most shitty SBC seen so far) also for A83T.

BTW: Comparing cpufreq governors accross different kernels isn't that useful since strategies differ. On Allwinner platforms better choose interactive. At least for server usage with ondemand you would have to tune a lot more things there, linux-sunxi wiki knows the details (search for cpufreq)

[Fourdee]

@ThomasKaiser

https://linux-sunxi.org/Cpufreq#The_.22ondemand.22_governor

If you allow very low scaling_min_freq values with ondemand/interactive the system might behave laggy

If the cpu load and overheads affects sampling rate ticks consistency, or the ability to sample, then yes. Although I wouldn't know.

If you allow very low scaling_min_freq values with ondemand/interactive the system might behave laggy and some timing critical stuff

Interesting, but for non-GPIO users, a realtime enabled kernel with a realtime hardware clock would be more beneficial for "time critical stuff"?

echo 408000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 25 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold

Or, for the same effect using a lower clock and possibly lower vcore:

echo 218000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold

And especially io_is_busy is essential if you want to use your sunxi device as file server)

This I didn't know. Will have to look into this option.

[k-plan]

@Fourdee

playing around with NanoPi NEO, with mounted FriendlyARM heat sink.

Using fresh installed DietPi V129 image.

:~# uname -a
Linux NeoPi 3.4.112-sun8i #2 SMP PREEMPT Sat Aug 6 18:07:55 BST 2016 armv7l GNU/Linux

Installed via dietpi-software : Build-Essentials and Git Client
Installed via apt-get : cpufrequtils and sysbench

Reading this: http://www.cnx-software.com/2016/03/17/rpi-monitor-is-a-web-based-remote-monitor-for-arm-development-boards-such-as-raspberry-pi-and-orange-pi/

For H3 devices not running Armbian:
wget http://kaiser-edv.de/tmp/4U4tkD/install-rpi-monitor-for-h3.sh
chmod +x install-rpi-monitor-for-h3.sh
./install-rpi-monitor-for-h3.sh
to install rpimonitor with a H3 template (for OPi), with work as well for NanoPi Neo.

Reading this: http://forum.armbian.com/index.php/topic/1614-running-h3-boards-with-minimal-consumption/#entry14381

http://www.cnx-software.com/2016/08/23/nanopi-neo-board-gets-armbian-debian-8-ubuntu-16-04-with-linux-4-6-4-7-mainline-h3consumption-power-consumption-tool/

h3consumption
wget https://github.com/igorpecovnik/lib/raw/master/scripts/h3consumption
chmod +x h3consumption
echo 'Thanks to T. Kaiser;' > /etc/armbian.txt
./h3consumption

Watch rpimonitor Web-Interface and start:
sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=$(grep -c '^processor' /proc/cpuinfo)

• without any changes (default: max. CPU-Freq: 1200 MHz , DRAM-Freq: 624 MHz and Governor: ondemand):

Test execution summary:
    total time:                          186.7981s

---

• change Governor via dietpi-config to interactive:

Test execution summary:
    total time:                          170.0824s

---

• now change DRAM Freq to 408 MHz : ./h3consumption -d 408

Test execution summary:
    total time:                          169.2697s    

---

Graphic overview (all three test):

conclusion:

• Governor: interactive with DRAM-Freq: 408 MHz and max. CPU-Freq: 1200 MHz
  seem to be best combination on NanoPi Neo with a heat sink for maximum load with great performance.

@Fourdee
I think, it will be a good default choice for your next NanoPi Neo image.

---

Testing:

• Lower max. CPU-Freq. to 912 MHz (for user with out a heat sink): cpufreq-set -u 912MHz

Test execution summary:
    total time:                          203.6728s

conclusion:

• Governor: interactive with DRAM-Freq: 408 MHz and max. CPU-Freq: 912MHz
  seem to be a good combination on NanoPi Neo without a heat sink to lower CPU temperature, but it will cost some performance.

[Fourdee]

@k-plan

Epic testing and report :+1:

change Governor via dietpi-config to interactive:

Was 16 seconds quicker.
I'am just wondering if we should switch to interactive for all DietPi images by default?
If we can test some of the main boards (eg: RPi), and verify they have improved results with interactive, seems logical?

DRAM-Freq: 408 MHz and max. CPU-Freq: 912MHz seem to be a good combination on NanoPi Neo without a heat sink to lower CPU temperature, but it will cost some performance.

Looks like those settings are now default in ARMbian neo.fex https://github.com/igorpecovnik/lib/commit/95fa82256fe3fdf6db0e2f22d0884419989a1e8c

I'll patch it to our users.

[ThomasKaiser]

It's really great that you provided the screenshots since this makes it more easy to explain the mistakes made when testing.

First: sysbench is crap as used now. Always. You find all reasons here: http://forum.armbian.com/index.php/topic/1748-sbc-consumptionperformance-comparisons/

You started with ondemand governor and then switched to interactive. Useless for this mode of operation since throttling already occured so interactive, ondemand and performance MUST behave exactly the same.

Then: sysbench does not depend on DRAM clockspeed but temperature on the NEO highly depends on DRAM clockspeed. You started with 624 MHz (set by u-boot), then as soon as throttling started BSP kernel switched to 432 (set in fex file). This is the only possible reason why the result you attribute to 'ondemand' (186.7981s) differs from the one you attribute to 'interactive' (170.0824s). You would have to repeat this test using h3consumption before to ensure SoC remains at the same DRAM clockspeed.

Then you reduced DRAM clockspeed from 432 to 408 MHz the correct way which is known to make a huge difference on SoC temperature (lower DRAM clockspeed, lower temperatures, less throttling) and still use a 'benchmark' that is not affected by DRAM clockspeed at all (so using this tool is inappropriate anyway since most real world workloads do not run from caches inside the CPU but depend on access to DRAM!). Why execution time only marginally improves is strange or let's better say an indication to repeat the test.

When you lower max cpufreq to 912 MHz then this affects performance with this specific inappropriate benchmark test (too short) since unlike before now the SoC can not start with 1200 MHz until throttling starts but is limited to 25 percent less performance but also remains at the lower VDD_CPUX voltage which ensured that no throttling occured.

TL;DR:

• you did not test different cpufreq governors (as soon as maximum cpufreq is reached and throttling starts there is no difference in behaviour), you did not even test realistic workloads
• interactive is still the way better choice with Allwinner BSP kernel (see how network performance is affected). Individual kernels perform differently here, so it's a per platform decision
• limiting max cpufreq to 912 MHz is not that useful unless you want to ensure that this specific SBC always remains on the lower VDD_CPUX voltage to limit maximum consumption (see an example how mainline kernel on the NEO and other H3 boards currently sucks here)
• Armbian defaults are optimized for IoT useage with NEO (not exceeding 2W maximum consumption -- we come out of u-boot now with 480 MHz cpufreq and 408 MHz DRAM clockspeed, you use different u-boot settings here so unless you adopt this change also it's pretty useless to limit max cpufreq from 1200 to 912 MHz
• Armbian enabled NEO users to adjust these settings to their needs so it's easy for them to regain higher default performance while allowing max consumption to reach 3W. My personal opinion is that something like that would be necessary if max consumption will be lowered.

Additional note: The way you tested (execution times way too short) you will get totally different results using a different heatsink than FriendlyARM's. A directly connected heatsink acts differently. With FA's you need test execution times of at least 10 minutes to get constant behaviour.

[k-plan]

@ThomasKaiser

👍 yes you are totally right!

Sollte auch kein "wirklicher" Test sein, der deinen das Wasser reichen kann.
War nicht meine Absicht oder mein Ziel. Kann ich auch gar nicht.
Man sollte vielleicht im Auge behalten, ich bin einfacher "noobs" oder "DAU" mit Null Komma Nix Ahnung von Linux, Kernel, Programmierung, Entwicklung Scripting oder was auch immer. Schon das nachzumachen oder nur in Ansätzen zu verstehen, über was ihr hier sprecht, fällt mir sehr schwer.

Was ich Fourdee mit primitiven Mitteln zeigen wollte ist folgendes.
Wir sollten im DietPi Image für NanoPi Neo, was auf armbian aufbaut:

• den Governor per default auf interative setzen
• die DRAM Freq. auf 408 MHz limitieren
• (und jedem dringend empfehlen, einen vernünftigen Kühler zu montieren - aber schon das wird uns nicht gelingen! 😉 )
• daher könnte es gut sein, noch zusätzlich in dietpi-config die Option zu haben, max. CPU Freq. auf deine vorgeschlagenen 912 MHz zu begrenzen.

Denn damit verschenken wir nichts, wir gewinnen nur.

Eigentlich genau dass, was du uns mit deinem Eingangsposting auch mitteilen wolltest, wenn ich dich richtig verstanden hatte. 😄

Wenn nicht, sag bitte einfach an, was du empfehlen würdest.

DietPi verfolgt auch einen anderen Ansatz als armbian.
Für Trottel wie mich, Linux einfach beherrschbar zu machen. Schneller Erfolg, einfacher Einstieg, leichte Installation von Software, möglichst universell vorkonfiguriert, modular, schlank von Hause aus.
Und der gleiche "look and feel" auf vielen völlig verschiedenen SBC, wie alle RPi, Odroid, NanoPi, BananaPi, OrangePI, Pine64, ... und das ein unterschiedlichen Chips und Plattformen.

Armbian ist cool, technisch top, mit vielen tollen Inovationen unter der Haube, von denen die meisten wohl von Dir und Igor stammen. Ich mag Armbian sehr. Aber der Einstieg ist nicht leicht. Und Ihr habt es geschafft, den schrottigen Allwinner Mist , vollkommen Abseits des Hersteller Supports, endlich zum fliegen zu bekommen! Dafür meinen tiefsten Respekt!
Mein Cubietruck würde ohne Euch wahrscheinlich bis heute noch nicht vernünftig laufen.
Toll das Ihre euch dort so engagiert, euch reinhängt und euer Wissen teilt.

[k-plan]

@Fourdee

change Governor via dietpi-config to interactive:

hmm, did this, because tkaiser wrote:

Interactive does a much better job on this kernel and almost immediately switches from lowest to highest clockspeed when necessary.
....
BTW: Comparing cpufreq governors accross different kernels isn't that useful since strategies differ. On Allwinner platforms better choose interactive. At least for server usage with ondemand you would have to tune a lot more things there, linux-sunxi wiki knows the details (search for cpufreq)

If you have a look on the screenshots, you can see, what he wants do say.
Governors strategie do change things in VCore, Cooling State, DRAM Freq. and max. CPU Freq.
And for sunix devices , where can be take influence on this via script.bin.

[cooler_table]
cooler_count = 11
cooler0 = "1200000 4 4294967295 0"
cooler1 = "1008000 4 4294967295 0"
cooler2 = "816000 4 4294967295 0"
cooler3 = "720000 4 4294967295 0"
cooler4 = "648000 4 4294967295 0"
cooler5 = "480000 4 4294967295 0"
cooler6 = "312000 4 4294967295 0"
cooler7 = "240000 4 4294967295 0"
cooler8 = "240000 3 4294967295 0"
cooler9 = "240000 2 4294967295 0"
cooler10 = "240000 1 4294967295 0"

RPi, Odroid, etc. do this by other ways. So without a really in-deep testing (by Thomas Kaiser) we don't shall do this.

And yes, my "testing methods" are crappy shit, only playing around, to get a feeling what T. Kaiser want to say to us. Hope he have pity with me/us.

Was 16 seconds quicker ...

Don't build on this. As T.Kaiser said, every time you let run a sysbench, there is a lightly different result. It is more a trend, not a measurement tool.

[Fourdee]

@ThomasKaiser

First: sysbench is crap as used now.

Ok, which alternative would you recommend?

limiting max cpufreq to 912 MHz is not that useful unless you want to ensure that this specific SBC always remains on the lower VDD_CPUX voltage to limit maximum consumption (see an example how mainline kernel on the NEO and other H3 boards currently sucks here)

So forcing the 912MHz max clock is irreverent, unless the user wants to only lower power consumption? You are saying the device can and will run to the 1200MHz clocks? I assume with thermal throttling protecting the H3 from high temps?

you did not test different cpufreq governors (as soon as maximum cpufreq is reached and throttling starts there is no difference in behaviour), you did not even test realistic workloads

Ondemand sampling could be a factor in those results. Possibly the Ondemand sampling uses more CPU time than the interactive sampler?

Armbian defaults are optimized for IoT useage with NEO (not exceeding 2W maximum consumption -- we come out of u-boot now with 480 MHz cpufreq and 408 MHz DRAM clockspeed, you use different u-boot settings here so unless you adopt this change also it's pretty useless to limit max cpufreq from 1200 to 912 MHz

Interesting, are you only doing this for the NanoPi Neo, or, can we expect all ARMbian images to promote low energy consumption for IoT uses by reducing max clocks and vcore by default?

Armbian enabled NEO users to adjust these settings to their needs so it's easy for them to regain higher default performance while allowing max consumption to reach 3W.

How?

With FA's you need test execution times of at least 10 minutes to get constant behaviour.

Why 10 minutes?

totally different results using a different heatsink than FriendlyARM's.

Thats the same for any custom/aftermarket heatsink. Any one heatsink could be more efficient than the other. I fail to see your point.

[ThomasKaiser]

Just two quick notes: Please read again through last posts of this thread to get the idea what might happen when NEO will run at above 912 MHz (it's more about preventing deadlocks than anything else since the thermal behaviour of this board is so different than the other H3 devices).

And if you then compare the FA heatsink (thermal pad, huge) with those normally used (directly attached not that huge) you get different characteristics how fast the SoC heats up and how slow it cools down again. It's simply a different type of heatsink showing completely different behaviour (same for Beelink X2 for example where the same principle is used)

[Fourdee]

@ThomasKaiser

Just two quick notes: Please read again through last posts of this thread to get the idea what might happen when NEO will run at above 912 MHz (it's more about preventing deadlocks than anything else since the thermal behaviour of this board is so different than the other H3 devices).

Ok, so lets break theses links and posts down. Your findings are:

1. In your opinion, Sysbench is crap.
2. Sysbench results can be varied, depending on the compiler options used to create the Sysbench binary. One could say, to ensure "accurate results" across same CPU architectures, you should compile the binary yourself and use that binary on each tested device.
3. Comparing benchmarks across different CPU architectures will create vastly different results. Well yes, newer CPU instructions (SSE/AVX/Neon) sets/extensions are designed to be an improvement on the previous.
4. 1200mhz Neo = Hard lock after 2 minutes. I do remember you mentioning this previously :+1:

And if you then compare the FA heatsink (thermal pad, huge) with those normally used (directly attached not that huge) you get different characteristics how fast the SoC heats up and how slow it cools down again. It's simply a different type of heatsink showing completely different behaviour (same for Beelink X2 for example where the same principle is used)

The heatsink and thermal compound you use, has a direct implication to the thermal dissipation performance of the CPU.

[Fourdee]

http://forum.armbian.com/index.php/topic/1748-sbc-consumptionperformance-comparisons/#entry14164
the best example is the NEO: When trying to run the test with only FriendlyARM's heatsink, no fan and allowing 1200 MHz clockspeed the board simply deadlocks after running cpuminer for 25 minutes at 64°C SoC temperature reported.

./minerd --benchmark

No heatsink. Thermal throttling is working correctly:

• Drops clocks to 816mhz @ 70'c.
• Drops clocks to 720mhz @ 75'c

Running stable 30+ minutes.

[ThomasKaiser]

The problem is most probably located between heatsink and board. I wrote I used FA's heatsink. This one does a great job since it spreads heat away from SoC through the thermal pad. All other PCB components around get less airflow and are therefore more prone to overheating than before.

Please touch U7 nearby the SoC for a few seconds or at least until it really hurts and your skin is burned. FA's heatsink improves heat dissipation for the SoC but negatively influences heat dissipation of other 'hot stuff' around.

It would be worth a try to use a larger thermal pad that also covers U7 but that's FA's job and not ours. Since I'm not sure whether they tested the same way like we (they would be the first SBC vendor ever thinking about higher loads than laughable stuff like 'yes >>/dev/zero') it's safer to remain at 912 MHz (at least for Armbian with professional use cases in mind).

In other words: I managed to deadlock the board with FA's heatsink but (IIRC) not without.

[Fourdee]

@ThomasKaiser

In other words: I managed to deadlock the board with FA's heatsink but (IIRC) not without.

:+1:

U7

Your right, i'd say U7 runs 25'c+ hotter than what the H3 is throwing out.

I attached a heatsink to H3 and U7 with thermal adhesive tape
So with heatsink on the H3, thermal throttling occurs:

• 1008Mhz @ 65'c
• 818Mhz @ 70'c
  Levels out around 68-72'c

But touching the hex nut (U7), temp is well beyond that. Negligible heat from RAM. Overheating U7 is the issue for deadlock i'd imagine?

[ThomasKaiser]

Overheating U7 is the issue for deadlock i'd imagine?

I don't know. I can only do some testing and hope to learn in the meantime to document everything that's necessary for more knowlegeable people like me (when it comes to electronics) to draw the right conclusions. Maybe it's the result of a combination of more than one issue and it's FA's issue anyway. We're happy with the 912 MHz max already and in case Armbian users want to push the envelope they're enabled to do so on their own risk (h3consumption tool should allow them to tweak settings)

They should either come up with a better heatsink design (larger thermal pad but maybe this will lead to overheating the DRAM when it not only covers U7) or replace heat generator U7 with a better buck converter instead on new PCB revision.

[Fourdee]

When creating DietPi images, based on ARMbian, we always use the default fex settings.
As far as I can tell 912MHz is not currently enforced by ARMbian: https://github.com/igorpecovnik/lib/blob/e6903c1fd4cbec222a2e584db906fc9c92e20a22/config/fex/nanopineo.fex#L738-L752

Please correct me if i'am incorrect.

[ThomasKaiser]

912 MHz is default for both NEO and AIR. As already explained we use cpufrequtils. Users are free to do whatever they want, we even include a tool called h3consumption to adjust this to get really lightweight operation on all supported H3 devices or to allow NEO/AIR users override our defaults.

BTW: NEO PCB rev 1.1 fixed heat issues partially and I would assume that's the same with AIR.