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?
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?
