Pine 64 benchmarks

[Andrew2]

We are currently working with a reputable heat sink vendor to design a heat sink and samples will available on next week. The size is 35x42x5mm, Aluminum body with copper coating. The bottom of this heat sink has three self-adhesive pads that covers 2 SDRAM and the A64 SoC. We will send to Andrew2 to try out when receive the sample.

Good to know, then I'll leave the second Pine64+ as it is, wait for your heatsink sample, will then run tests again and report back.

I did another run with more demanding workloads as the boring PTS 'benchmarks' today to demonstrate how efficient our new settings influence thermal/throttling and also performance behaviour of longsleep's OS images.

I took the Pine64+ with heatsink, put the fan on top and used ssvb's great cpuburn-a53 from https://github.com/ssvb/cpuburn-arm to generate as much heat as possible. Then I walked through the available cpufreq operating points (/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies) that differ now. 

Before:

Code:

480000 600000 720000 816000 1008000 1104000 1152000 1200000 1344000

And after:

Code:

480000 600000 720000 816000 912000 960000 1008000 1056000 1104000 1152000 1200000 1344000

Being able to use more different clockspeed steps increases performance when throttling occurs. But more importantly we also adjusted the thermal trip points and the strategy how to prevent overheating (not killing CPU cores but let throttling do the work). On the left our new settings, on the right how throttling worked before (or works still on the Android image!):



With my cheap equipment (heatsink+fan for less than $3) and the new settings throttling starts when reaching 90°C and the maximum cpufreq jumps between 912MHz and 960MHz. But all CPU cores are kept. Please keep in mind that running the meaningless 'Phoronix Test Suite' benchmarks the very same setup was able to clock at up to 1344MHz which is just an indication how demanding cpuburn-a53 is (makes heavy use of NEON).

With the old settings higher clockspeeds would have been possible but CPU cores would've been killed all the time. Please keep in mind that longsleep added a tricky service at least to his Ubuntu image: A small daemon called core-keeper watches available CPU cores and the 'cooler state' and when temperatures are ok brings the CPU cores back. Without this the first full load situation will lead to all CPU cores killed up to 1 or maybe 2. I believe the current strategy to throttle earlier but keep CPU cores is superiour.

And please also keep in mind that I used a really heavy workload you might not be able to create using normal/unoptimised software. So adopting these new thermal settings will not limit your maximum clockspeeds to 912-960 MHz as in my extreme example setup but keep them at the maximum (maybe a cheap heatsink is necessary) but more importantly keeps all CPU cores active.

Fortunately longsleep provides an easy way to update all his images (both kernel and u-boot), so please follow these steps when you're already using his images:

Code:

bash <(curl -s https://raw.githubusercontent.com/longsleep/build-pine64-image/master/simpleimage/platform-scripts/pine64_update_uboot.sh)
bash <(curl -s https://raw.githubusercontent.com/longsleep/build-pine64-image/master/simpleimage/platform-scripts/pine64_update_kernel.sh)