(09-20-2016, 01:18 AM)mikey0000 Wrote: 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
(09-20-2016, 01:18 AM)mikey0000 Wrote: 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
