From cnx-software.
First invocation on Rock 5B in lazy mode (phoronix-test-suite benchmark pts/stockfish-1.4.0) already ended up with the board freezing at the 2nd stockfish run. Attaching fan to power and repeating again also again freeze during 2nd stockfish bench 128 8 24 default depth run.
General problem was already known since so far on some boards highest DRAM clock wasn't usable and users needed to switch from 2112 MHz to 1560 MHz for stable operation.
My board hasn't seen any freezes on highest DRAM clock so this was a surprise. By updating my Armbian image to latest version I was hoping for getting most recent boot BLOBs as part of u-boot package. It now reads ii linux-u-boot-rock-5b-legacy 22.11.0-trunk.0106 arm64 Uboot loader 2017.09 but problems got even worse and now the board freezes on 2112 MHz DRAM clock already at 1st benchmark execution. Maybe @amazingfate can comment on whether my OS image is expected to run on latest BLOBs or not?
With lower DRAM clock everything works as expected but at 2112 MHz DRAM clock the board freezes regardless of the A76's clockspeeds (and as such DVFS/consumption) so it looks solely related to DRAM clock:
| A76 clock |
DRAM clock |
Watts |
SoC temp |
Nodes per second |
| 2360 MHz |
528 MHz |
8-9W |
40°C |
3238057 |
| 2360 MHz |
1068 MHz |
9-10W |
43.5°C |
4122771 |
| 2360 MHz |
1560 MHz |
10-11W |
46°C |
4653285 |
| 2360 MHz |
2112 MHz |
12W |
46°C |
freeze |
| 1800 MHz |
2112 MHz |
8-9W |
39°C |
freeze |
With other CPU benchmarks I haven't seen consumption exceeding 9W on Rock 5B so stockfish is really a potent load generator / stability tester. On top of making heavy use of SIMD extensions it also is heavy on memory access: walking through the different DRAM clockspeeds ended up with significantly different scores: https://openbenchmarking.org/result/2211099-NE-2211093NE82
Quick check on an AMD EPYC 7232P (8C/16T) thing also hints at stockfish being more demanding than both cpuminer and 7-zip:
First chart is from a NetIO powermeter (measuring at the wall), 2nd is the server's internal BMC showing PSU1 (PSU2 is always in standby on this machine so the whole productive consumption is PSU1's thing), the last two are the BMC measurements for CPU and DRAM separately (though no idea to which number the memory controller contributes):
From cnx-software.
First invocation on Rock 5B in lazy mode (
phoronix-test-suite benchmark pts/stockfish-1.4.0) already ended up with the board freezing at the 2ndstockfishrun. Attaching fan to power and repeating again also again freeze during 2ndstockfish bench 128 8 24 default depthrun.General problem was already known since so far on some boards highest DRAM clock wasn't usable and users needed to switch from 2112 MHz to 1560 MHz for stable operation.
My board hasn't seen any freezes on highest DRAM clock so this was a surprise. By updating my Armbian image to latest version I was hoping for getting most recent boot BLOBs as part of
u-bootpackage. It now readsii linux-u-boot-rock-5b-legacy 22.11.0-trunk.0106 arm64 Uboot loader 2017.09but problems got even worse and now the board freezes on 2112 MHz DRAM clock already at 1st benchmark execution. Maybe @amazingfate can comment on whether my OS image is expected to run on latest BLOBs or not?With lower DRAM clock everything works as expected but at 2112 MHz DRAM clock the board freezes regardless of the A76's clockspeeds (and as such DVFS/consumption) so it looks solely related to DRAM clock:
With other CPU benchmarks I haven't seen consumption exceeding 9W on Rock 5B so
stockfishis really a potent load generator / stability tester. On top of making heavy use of SIMD extensions it also is heavy on memory access: walking through the different DRAM clockspeeds ended up with significantly different scores: https://openbenchmarking.org/result/2211099-NE-2211093NE82Quick check on an AMD EPYC 7232P (8C/16T) thing also hints at
stockfishbeing more demanding than bothcpuminerand7-zip:First chart is from a NetIO powermeter (measuring at the wall), 2nd is the server's internal BMC showing PSU1 (PSU2 is always in standby on this machine so the whole productive consumption is PSU1's thing), the last two are the BMC measurements for CPU and DRAM separately (though no idea to which number the memory controller contributes):