I thought I check the situation with common enclosures in the future. Usually enclosure makers don't think a second about thermal issues and then you end up with serious performance degradations. While the Phoronix Test Suite can't show the 'raw performance' of different systems due to many design flaws (most importantly when misused with modern SBCs due to ignoring thermal/throttling issues) at least the test suite can be used to demonstrate thermal behaviour.
Please have a look at the last two entries here: http://openbenchmarking.org/result/16031...603083GA70
This is absolutely the same hardware and the same OS image using the same kernel, U-Boot and so on.
The differences are compiler and throttling settings (software) and the last run was with the Pine64+ without heatsink jailed in a small cardboard box to emulate an enclosure. Compared with the run before (Pine64+ with less aggressive throttling settings, wearing a heatsink and a small 5V fan) it's obvious what's happening:
![[Image: RPi-Monitor.png]](http://kaiser-edv.de/tmp/mc6CyL/RPi-Monitor.png)
![[Image: Pine64_in_Enclosure.png]](http://kaiser-edv.de/tmp/mc6CyL/Pine64_in_Enclosure.png)
What can not be seen on the graphs is the count of available CPU cores. I disabled it since otherwise the graphs would've looked too weird. But when running the multithreaded tests the BSP kernel's throttling strategy quite often killed cpu3 and cpu2 and if longsleep would'nt have already included a 'core keeper' service in his Ubuntu image I would've ended up with a dual core system pretty soon after starting the tests. Longsleep's service checks the cooler state and brings back killed cores when it's below a certain treshold:
Please have a look at the last two entries here: http://openbenchmarking.org/result/16031...603083GA70
This is absolutely the same hardware and the same OS image using the same kernel, U-Boot and so on.
The differences are compiler and throttling settings (software) and the last run was with the Pine64+ without heatsink jailed in a small cardboard box to emulate an enclosure. Compared with the run before (Pine64+ with less aggressive throttling settings, wearing a heatsink and a small 5V fan) it's obvious what's happening:
What can not be seen on the graphs is the count of available CPU cores. I disabled it since otherwise the graphs would've looked too weird. But when running the multithreaded tests the BSP kernel's throttling strategy quite often killed cpu3 and cpu2 and if longsleep would'nt have already included a 'core keeper' service in his Ubuntu image I would've ended up with a dual core system pretty soon after starting the tests. Longsleep's service checks the cooler state and brings back killed cores when it's below a certain treshold:
Code:
root@pine64plus:/etc/rpimonitor# /usr/local/bin/armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time CPU load %cpu %sys %usr %nice %io %irq CPU
09:54:30: 1008MHz 4.76 91% 1% 88% 0% 1% 0% 90°C 4 cores active
09:54:35: 816MHz 4.70 91% 1% 88% 0% 1% 0% 90°C 4 cores active
09:54:40: 1008MHz 4.73 91% 1% 88% 0% 1% 0% 95°C 2 cores active
09:54:46: 1008MHz 4.75 91% 1% 88% 0% 1% 0% 93°C 4 cores active
09:54:51: 1008MHz 4.69 91% 1% 88% 0% 1% 0% 88°C 4 cores active
09:54:56: 600MHz 4.63 83% 1% 80% 0% 1% 0% 95°C 2 cores active
09:55:01: 1008MHz 4.82 91% 1% 88% 0% 1% 0% 92°C 4 cores active
09:55:07: 816MHz 4.76 91% 1% 88% 0% 1% 0% 88°C 4 cores active
09:55:12: 600MHz 4.78 91% 1% 88% 0% 1% 0% 93°C 4 cores active