LOL! Too funny! 
I did exactly that. Of course not relying on this Geekbench garbage but by examining SoC and software behaviour.
And on RK3588 (as well as RK3566/RK3568) we’re dealing with PVTM which usually results in the rather uninteresting little cores clocking in at 1800 MHz but the more important A76 ones being clocked up to 2400 MHz: Knowledge/articles/Quick_Preview_of_ROCK_5B.md at master · ThomasKaiser/Knowledge · GitHub
We’ve recently seen some comical PVTM failure resulting in the A76 cores being clocked at only 400 MHz.
While Geekbench is that stupid to rely on some sysfs entries that claim certain clockspeeds. And the 1800 MHz you were fooled by is due to Geekbench presenting the clockspeed of cpu0 which on ARM is usually a little core. Geekbench just generates some funny numbers and its target audience usually doesn’t give a sh*t but blindly trusts into these numbers.
Then maybe you should better look at my sbc-bench than this Geekbench garbage…
sbc-bench tries to generate insights and not just numbers. See these two Rock 3A results:
http://ix.io/40TX: 7-zip multi-threaded score of 5110
http://ix.io/48eg: 7-zip multi-threaded score of just 2690
How is that possible? Fortunately sbc-bench results also contain the answers. It’s not just silicon variation (the RK3568 on the 2nd test clocks severly lower than 2000 MHz) but it’s broken thermal trip points AKA bad settings.
As for results variations with RK3568 we have
- PVTM
- boot BLOBs that do DRAM initialization (I have a couple of older sbc-bench results in my collection with really bad memory performance)
- relevant kernel config like
CONFIG_HZor thermal trip points resulting in moderate up to absurd throttling like above - different environmental conditions like temperature
- background activitly that ruins benchmark numbers
Geekbench doesn’t care about any of these, just generates and uploads random numbers.