Geekbench Scores for Android 7.0 with longsleep kernel?

[tkaiser]

Just curious: Did anyone already ran Geekbench on the latest Android 7.0 build with longsleep kernel?

I just ask since when we started tweaking cpufreq / dvfs scaling back in March it was pretty obvious that 'performance' of any demanding task lasting longer than 60 seconds depends on heat dissipation (hardware issue: enclosure vs. none, heatsink vs. none, heavy loads as cpuburn-a53 required already heatsink + fan) and on ths / throttling settings (software issue: killing CPU cores vs. reducing frequencies, providing more cpufreq steps vs. less and so on).

When looking through scores made for Android 5.1 (all with Allwinner's boring and outdated 3.10.65 kernel and most probably ths / cooler_table settings from hell) it looks like different environmental conditions have been 'benchmarked' (especially enclosure vs. none): https://browser.primatelabs.com/v4/cpu/s...q=PINE+A64

Is Geekbench smart enough to take throttling into account? Or at least reporting/monitoring (changes of) /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq?

[mikey0000]

I believe your looking for this
https://browser.primatelabs.com/geekbenc...C%93&q=a64

Look for user Ayufan - that build is against android 7 and longsleep

and yes its using longsleep, ayufans fork but still longsleep kernel

[tkaiser]

I believe your looking for this
https://browser.primatelabs.com/geekbenc...C%93&q=a64

Look for user Ayufan - that build is against android 7 and longsleep

and yes its using longsleep, ayufans fork but still longsleep kernel

Sorry, I've been unclear. I'm talking about ths / cooler_table settings used in ayufan's build, not strictly related to longsleep's kernel or not since using communty's device tree settings with the old Allwinner 3.10.65 kernel should also be sufficient.

In Geekbench browser there are results from Sep 4, in commit history I see a .dtb appear at the 7th (too lazy to grab and decompile it)  and some potential improvements made on the 18th. So that's the reason why I ask about 'latest build' since I'm not that much interested in historical data.

It's known over a year that Allwinner's defaults in their current BSP for H3, A83T and also A64 pretty much suck when it's about dealing with overheating, it's also known that Geekbench numbers for tiny Android devices pretty much suck (since they test partially heat dissipation and nothing else) so that's why I'm interested in latest scores made with devices where heat dissipation is known. Pine64 in a tiny enclosure without heatsink will get lower scores than one lying around with a huge heatsink applied. But with community THS / throttling settings the Pine64 in the small enclosure might score better since we did a lot of testing back then to improve throttling behaviour.

Currently no Pine64 around otherwise I would simply test myself

---

https://browser.primatelabs.com/geekbenc...C%93&q=a64

Well, thanks for this list anyway. There are a couple of results where Single-Core and Multi-Core Score are listed as being identical.

If these Android builds used Allwinner's original ths settings then that's most probably since Pine64 ran at this time with just one CPU core active since overheating occured before. Allwinner's default strategy to 'deal with' an overheating SoC is to kill one CPU core after the other until only one is left (and then starts to throttle if this is not enough). This is something we changed in longsleep's github repo in Feb and March but of course these settings have to be applied to Android images too. Otherwise performance sucks.

What happens can be read out in Android too, looks then like this for example: https://github.com/longsleep/build-pine6...-191594935

Our optimization process is documented there also. It started as an overclocking attempt but then we focused on reasonable goals instead

[ayufan]

I didn't yet run Geekbench on longsleep kernel.

My scores were run against Allwinner BSP.

[tkaiser]

As an example: This Pine64 is running Android 7.0 on just 3 CPU cores: https://browser.primatelabs.com/geekbench3/8027230 (single-core 533 vs. multi-core 1183)

While this Pine64 is running Android 7.0 on 4 CPU cores: https://browser.primatelabs.com/geekbench3/8027275 (single-core 534 vs. multi-core 1541)

The first test was at 'September 04 2016 08:42 PM', the 2nd at 'September 04 2016 09:00 PM', I would assume this is identical hardware and the only change is a reboot in between.

That's why I'm asking about adoption of our community settings (preventing killed CPU cores, providing more cpufreq steps allowing fine graded throttling increasing performance) now that longsleep's BSP kernel can be used with Android too (but it shouldn't matter, by simply throwing away Allwinner's ths settings and replacing them with our settings performance should improve regardless which BSP kernel version is used)

[ayufan]

The problem with Allwinner kernel and Android is that they do not write to `/sys/devices/soc.0/cpu_budget_cool.16/roomage` or `/sys/devices/soc.0/cpu_budget_cool.17/roomage`.

Thus they allow to shutdown CPU cores on idle and this makes to loose a lot of performance.

I did remove Allwinner stuff as this was overly complicated and was built deep into system and replaced it with simple power module: https://github.com/ayufan-pine64/device-...er_tulip.c

[tkaiser]

Thanks for the explanation. Killing idle CPU cores sounds pretty weird. I've done some tests with Allwinner's H3 a few weeks ago (and assume A64 behaves exactly identical) and there idle consumption with 1 vs 4 CPU cores active makes a difference of maybe 30mW (in other words: none or not able to measure correctly). Quoting linux-sunxi wiki:

Modern processors implement advanced clock gating for power saving purposes and if the processor is sitting on a WFI instruction, then the power consumption is already significantly reduced regardless of the CPU clock speed

So I would hope for cpufreq / dvfs scaling behaviour in Android comparable to Linux now (where we were able to get nice performance improvements by tweaking cpufreq / dvfs / ths settings back in March)