Pine 64 benchmarks

[xtcrefugee]

Thanks, this is very useful. It looks like heatsinks for the A64 are going to be strongly advisable then, it's a bit of a shame there wasn't an option for one directly from Pine.

[Andrew2]

Final run using the same board as used for the heatsink tests now with heatsink and fan together and 1344 MHz unlocked again: http://openbenchmarking.org/result/16031...603114GA85

The benchmark scores are rather irrelevant (at least if you want to compare different boards -- testing different thermal settings in an active benchmarking approach just allowed us to improve performance settings for Pine64 and to identify most if not all benchmarks used as insufficient)

But at least I could verify that the board runs again at these higher clockspeeds so I've to search for the cause of the shutdowns that happened this afternoon somewhere else (will use the 2nd Pine64+ without heatsink on the PMIC to torture with heavy switching between voltages). And I could also verify that using equipment for $3 the A64 is able to run with light workloads constantly at 1344MHz (two times throttling down to 1200MHz for a moment):



Since the Phoronix test suite uses extremely unoptimised code (and some of the tests run single threaded and scores will be adjusted by the count of CPU cores afterward -- what a joke) the workload is rather light. Using software that makes heavy use of NEON for example and with my cheap heatsink and fan I'm not able to exceed 1008 MHz (eg. using cpuburn-a53).

Now time to drop the Phoronix stuff and start to further optimise settings with real benchmarks like https://github.com/pooler/cpuminer for example

[Andrew2]

Thanks, this is very useful. It looks like heatsinks for the A64 are going to be strongly advisable then, it's a bit of a shame there wasn't an option for one directly from Pine.

Both not true fortunately 

If you don't do numbercrunching on the Pine64+ or try to run irrelevant benchmarks you might not need a heatsink at all. On the other hand users that think about using a pretty small enclosure should think about adding a heatsink or otherwise they might experience performance degradation under full constant CPU load (use monitoring to get an idea when and how often that happens unless you run moronically benchmarks).

And then there's another thing that should be considered. The Pine64 has a video engine called CedarX and also a somewhat weak GPU (Mali400). By being able to use these hardware engines (driver/software thing) stuff that might require already overclocking+heatsink on other ARMv8 designs (Raspberry Pi 3 trying to decode H.265 video for example) will run on the Pine64 with just slightly higher internal temperature. A64 is pretty similar to Allwinner's H3 and there we can decode H.264/H.265 using CedarX already in Linux flawlessly: http://forum.armbian.com/index.php/topic...es/?p=6009

For Android this is already the case (full CedarX/GPU support) and I would expect that it doesn't take that long until the same works in Linux too.

Regarding an heatsink option from the vendor. I think they were a bit surprised how heavy CPU bound workloads in Linux might differ from the Android situation. But @tllim wrote he's already in contact with a heatsink specialist and a customised heatsink for Pine64+ (covering also DRAM if I remember correctly) will be available. The one I use costs just 50 cents and already helps a lot. If they take care they can come up with a heatsink that improves heat dissipation a lot more.

[tllim]

Thanks, this is very useful. It looks like heatsinks for the A64 are going to be strongly advisable then, it's a bit of a shame there wasn't an option for one directly from Pine.

Both not true fortunately 

If you don't do numbercrunching on the Pine64+ or try to run irrelevant benchmarks you might not need a heatsink at all. On the other hand users that think about using a pretty small enclosure should think about adding a heatsink or otherwise they might experience performance degradation under full constant CPU load (use monitoring to get an idea when and how often that happens unless you run moronically benchmarks).

And then there's another thing that should be considered. The Pine64 has a video engine called CedarX and also a somewhat weak GPU (Mali400). By being able to use these hardware engines (driver/software thing) stuff that might require already overclocking+heatsink on other ARMv8 designs (Raspberry Pi 3 trying to decode H.265 video for example) will run on the Pine64 with just slightly higher internal temperature. A64 is pretty similar to Allwinner's H3 and there we can decode H.264/H.265 using CedarX already in Linux flawlessly: http://forum.armbian.com/index.php/topic...es/?p=6009

For Android this is already the case (full CedarX/GPU support) and I would expect that it doesn't take that long until the same works in Linux too.

Regarding an heatsink option from the vendor. I think they were a bit surprised how heavy CPU bound workloads in Linux might differ from the Android situation. But @tllim wrote he's already in contact with a heatsink specialist and a customised heatsink for Pine64+ (covering also DRAM if I remember correctly) will be available. The one I use costs just 50 cents and already helps a lot. If they take care they can come up with a heatsink that improves heat dissipation a lot more.

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.

[Artyom]

Thanks, this is very useful. It looks like heatsinks for the A64 are going to be strongly advisable then, it's a bit of a shame there wasn't an option for one directly from Pine.

Both not true fortunately 

If you don't do numbercrunching on the Pine64+ or try to run irrelevant benchmarks you might not need a heatsink at all. On the other hand users that think about using a pretty small enclosure should think about adding a heatsink or otherwise they might experience performance degradation under full constant CPU load (use monitoring to get an idea when and how often that happens unless you run moronically benchmarks).

And then there's another thing that should be considered. The Pine64 has a video engine called CedarX and also a somewhat weak GPU (Mali400). By being able to use these hardware engines (driver/software thing) stuff that might require already overclocking+heatsink on other ARMv8 designs (Raspberry Pi 3 trying to decode H.265 video for example) will run on the Pine64 with just slightly higher internal temperature. A64 is pretty similar to Allwinner's H3 and there we can decode H.264/H.265 using CedarX already in Linux flawlessly: http://forum.armbian.com/index.php/topic...es/?p=6009

For Android this is already the case (full CedarX/GPU support) and I would expect that it doesn't take that long until the same works in Linux too.

Regarding an heatsink option from the vendor. I think they were a bit surprised how heavy CPU bound workloads in Linux might differ from the Android situation. But @tllim wrote he's already in contact with a heatsink specialist and a customised heatsink for Pine64+ (covering also DRAM if I remember correctly) will be available. The one I use costs just 50 cents and already helps a lot. If they take care they can come up with a heatsink that improves heat dissipation a lot more.

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.

This is great!

Отправлено с моего SM-T325 через Tapatalk

[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)

[g_t_j]

Are these heatsinks http://www.ebay.co.uk/itm/191167775314?_...EBIDX%3AIT suitable for the SDRAM chips? I have a few of those available.

I'm also considering attaching something like this http://www.ebay.co.uk/itm/172088180004?_...EBIDX%3AIT on the processor's chip. I've read that the A53 chip itself is 14mm x 14mm square so one of those (15 x 15) above should do the job.

[tllim]

Are these heatsinks http://www.ebay.co.uk/itm/191167775314?_...EBIDX%3AIT suitable for the SDRAM chips? I have a few of those available.

I'm also considering attaching something like this http://www.ebay.co.uk/itm/172088180004?_...EBIDX%3AIT on the processor's chip. I've read that the A53 chip itself is 14mm x 14mm square so one of those (15 x 15) above should do the job.

The pure solid copper plate is the good heat sink.

[g_t_j]

Are these heatsinks http://www.ebay.co.uk/itm/191167775314?_...EBIDX%3AIT suitable for the SDRAM chips? I have a few of those available.

I'm also considering attaching something like this http://www.ebay.co.uk/itm/172088180004?_...EBIDX%3AIT on the processor's chip. I've read that the A53 chip itself is 14mm x 14mm square so one of those (15 x 15) above should do the job.

The pure solid copper plate is the good heat sink.

Yep, I think so. This is why I restricted my market search to pure copper heatsinks.

The question is how am I going to attach the above plate on the processor's chip? Do I have to use a drop of superglue?

[janjwerner]

http://www.aliexpress.com/item/FREE-Ship...50220.html
http://www.aliexpress.com/item/2-pcs-lot...87879.html

this is reasonable alternative if you can wait few days for shipping.
If you can wait a bit longer I would wait for heatsink that @tllim is working on. A large heatsink covering the SoC, memory and PMIC (with or without a larger fan) would be the best solution.