Rock 4 SE: Benchmarks vs Pi4B?

#1

The Rock 4 SE claims:

Why is ROCK 4 SE the perfect Raspberry Pi alternative?

  • Better performance – 4GB 64bit RAM, more processing cores and a broader memory interface,

Has anyone done benchmark comparisons?

I have a Pi4B 1.8GHz 2GB in my robot, and wondering how the Rock 4 SE will perform

ROS2 GoPiGo3 (w LiDAR, w Speaker)

  • Active:
    • GoPiGo3 Node
    • Distance Sensor Node
    • Ultrasonic Ranger Node
    • IMU Node
    • teleop_gopigo3_keyboard
    • ydlidar_test.py (still have to integrate ROS2 driver)
  • 25-37% CPU Load - 1 minute average load: 1.49, 15 min ave load: 1.0 (out of 4.0 cores)
    • htop reports GoPiGo3 node: 22% CPU
    • IMU node: 16% CPU,
    • US Ranger node: 3% CPU
    • Distance Sensor: 1% CPU
    • ydlidar_test: 2% CPU
  • 600MB memory used - free -h reports 1.2G available of 1.8G total
  • 6.7W (0.67A at 9.9v)
  • Proc Temp: 60’C
1 Like
#2

These are my results using sysbench

Sysbench Notes

== install
sudo apt install sysbench

=== Command Line Options

Ref: https://github.com/akopytov/sysbench#general-command-line-options

== RUN TESTS

$ sysbench cpu --threads=3 [–time=300] run
$ sysbench memory run

$ sysbench fileio --file_test_mode=“rndrw” prepare
$ sysbench fileio --file_test_mode=“rndrw” run
$ sysbench fileio --file_test_mode=“rndrw” cleanup
sysbench threads --threads=(number of cores) run

=== RESULTS

On Pi4B 2GB (1.8MHz) w/low profile heatsink, mounted in GoPiGo3 robot

  • sysbench --threads=3 --time=300 run

    • uptime 1min load 3.2
    • reached 65-76degC
    • Max Robot Battery Load: 7W (4.8W idle)

  • sysbench memory run

    • 2414.03 MiB/sec

  • sysbench fileio rndrw

    • read: ~4.8 MiB/s
    • write: ~3 MiB/s

  • sysbench threads --threads=4 run

    • 4 threads: ~13k events

  • SBC-Bench (ref https://github.com/ThomasKaiser/sbc-bench)

|   Device / details                              |Clockspeed|Kernel|   Distro                 |7-zip | AES   | AES   | mem  | mems |kH |
                                                                                               |      |128_16 | 256-16| cpy  | set  | /s|
| RPi 4 Model B Rev 1.5 / BCM2711 Rev C0 or later | 1800 MHz | 5.15 | Ubuntu 22.04.1 LTS arm64 | 5380 | 45430 | 36260 | 2410 | 3110 | - |

I’ll post the comparable results for the Rock SE when it gets to me.

#3

sysbench is such a poor choice:

the 64-bit sysbench cpu test at stock speeds is 12.5 times faster than the overclocked 32-bit result and 14.6 times faster than 32-bit at stock speeds.

I would look instead at sbc-bench (disclaimer: I started with sbc-bench almost 5 years ago since benchmark situation with SBC sucked that much).

1 Like
#4

This comparison was posted today:

#5

Fair comparison doesn’t mean that You need to compare same sd card just because one of board has limited storage options. Also support level for both boards can be different and same name for operation system doesn’t mean that you will get same platform and comparable results.
Also measuring heat and performance just without any heatsink and cooling is rather poor idea, will You do the same with regular PC or GPU?
Your startup test stuck on pi on some network tasks, is that “benchmark” ok?

1 Like
#6

That video is not mine, BTW.

Indeed temperature comparisons are totally impossible without having comparable processor cooling.

#7

I saw an announcement for the Rock Pi SE and wondered how would it do in my Raspberry Pi4 GoPiGo3 robot? The mounting in the robot requires a low profile heatsink on the processor. sbc-bench did not show temperature throttling with a max temperature of 72.1degC.

It would be possible to mount the Rock Pi SE in the robot with the same low profile heatsink on the processor, although the heatsink would be facing down, which is not the best orientation. The robot would not permit the giant heatsink recommended for the Rock 4 SE, so I ran this test with the same low profile heatsink used for the Raspberry Pi 4B test. The configuration produced an sbc-bench max temperature of 88.8degC bottom down, and 86.2degC bottom up with temperature induced throttling.

I don’t really know how to interpret the numerical results, but the temperature result is very concerning. To use the Rock 4SE in the GoPiGo3 robot will require extensive modification to allow for the large heatsink.

The results:

Raspberry Pi4B 2GB (1.8MHz) w/low profile heatsink on processor facing upwards in GoPiGo3 robot

Full Result:  http://ix.io/4dx4

NO THROTTLING:
Time       fake/real    load %cpu %sys %usr %nice %io %irq   Temp   VCore
14:46:05: 1800/1800MHz  4.08  92%   2%  89%   0%   0%   0%  72.1°C  0.9460V

|   Device / details	                          |Clockspeed     |Kernel|	Distro	            |7-zip |  AES  | AES   | mem  | mems |kH |
                                                                         |                                 |128_16 | 256-16| cpy  | set  | /s| 
| RPi 4 Model B Rev 1.5 / BCM2711 Rev C0 or later | 1800 MHz      | 5.15 | Ubuntu 22.04.1 LTS arm64 | 5380 | 45430 | 36260 | 2410 | 3110 | - |

Rock Pi 4 SE (Shows as ROCK PI 4B 1512/1008 MHz), w/same low profile heatsink on processor 1cm clearance

Result Details:  http://ix.io/4dHv  (bottom down)
                 http://ix.io/4dIv  (bottom up)

THROTTLING OCCURRED:
Time       big.LITTLE   load %cpu %sys %usr %nice %io %irq   Temp
19:05:47: 1416/1008MHz  5.57  89%   0%  88%   0%   0%   0%  88.8°C  (low profile heatsink on processor, board bottom down)
01:16:04: 1512/1008MHz  5.50  94%   0%  93%   0%   0%   0%  86.2°C  (low profile heatsink on processor, board bottom up)


|   Device / details	                          |Clockspeed     |Kernel|	Distro	            |7-zip |  AES   | AES   | mem  | mems |kH |
                                                                         |                                 |128_16  | 256-16| cpy  | set  | /s| 
| ROCK PI 4B                                      | 1512/1008 MHz | 4.4  | Ubuntu 20.04.5 LTS arm64 | 4800 | 286660 | 857250| 3460 | 8210 | - |
#8

Thank you for those two benchmark runs! I’m going to tag @willy because there are some insights…

So this somehow confirms that with Rockchip’s 4.4 BSP kernel from 2016 PVTM is also at work with RK3399, the Rock 4SE relies on RK3399-T (just like the el cheapo ROCK Pi 4 Model C+ variant) and this silicon variant will automagically be limited to 1.5/1.0 GHz even when running with an OS image made for Rock 4B (which comes with a RK3399 and not RK3399-T):

Checking cpufreq OPP for cpu0-cpu3 (Cortex-A53):

Cpufreq OPP: 1008    Measured:  996    (998.278/996.843/995.015)     (-1.2%)
Cpufreq OPP:  816    Measured:  806    (806.961/806.788/806.730)     (-1.2%)
Cpufreq OPP:  600    Measured:  590    (590.798/590.772/590.617)     (-1.7%)
Cpufreq OPP:  408    Measured:  399    (399.254/399.042/398.960)     (-2.2%)

Checking cpufreq OPP for cpu4-cpu5 (Cortex-A72):

Cpufreq OPP: 1512    Measured: 1505 (1505.396/1505.328/1505.328)
Cpufreq OPP: 1416    Measured: 1409 (1409.800/1409.650/1409.620)
Cpufreq OPP: 1200    Measured: 1193 (1193.717/1193.636/1193.474)
Cpufreq OPP: 1008    Measured: 1001 (1001.681/1001.515/1001.491)
Cpufreq OPP:  816    Measured:  809    (809.605/809.605/809.586)
Cpufreq OPP:  600    Measured:  593    (593.660/593.660/593.634)     (-1.2%)
Cpufreq OPP:  408    Measured:  400    (401.027/400.972/400.879)     (-2.0%)

The PVTM values are as follows:

       cpu cpu0: temp=45000, pvtm=150955 (150691 + 264)
       cpu cpu0: pvtm-volt-sel=2
       cpu cpu4: temp=45000, pvtm=157609 (157469 + 140)
       cpu cpu4: pvtm-volt-sel=2

Only a few RK3399(-T) devices today still run with Rockchip’s BSP kernel so this PVTM info is very rare. Here’s a Tinkerboard 2/2S with 4.19 clocking at 2.0/1.5 GHz:

       cpu cpu4: temp=42222, pvtm=156795 (156760 + 35)
       cpu cpu4: pvtm-volt-sel=2

And another Tinkerboard 2/2S also running 4.19 and also clocking at 2.0/1.5 GHz:

       cpu cpu4: temp=32222, pvtm=156141 (156780 + -639)
       cpu cpu4: pvtm-volt-sel=2

Somehow the BSP kernel detects the RK3399-T variant and limits clockspeeds to 1.5/1.0 GHz for the A72/A53 cores. The benchmark results tell that RK3399-T is slightly slower than BCM2711 at 1.8 GHz with most tasks and that the RK3399-T silicon variant is most probably garbage when throttling down to 1200 MHz even with a heatsink attached.

@CyCob can you please try to run sbc-bench in extensive mode so the output also contains the so called DVFS OPP tables?

export MODE=extensive
sbc-bench
1 Like
#9

Not much surprising to me. I’ve always been disappointed by the design of the RK3399 when it comes to CPU distribution. You have roughly the same CPU power in the 4 little cores as the 2 big ones, except that there’s no way to use them to perform well on single-threaded tasks. Proposing twice as many small cores as the big ones simply makes no sense at all, because either it’s only to run mostly idling tasks and you don’t need that many cores, or you plan to saturate them and you’re constantly waiting for them. In this regard, the BCM2711 is way better with 4 real cores. Where the RK3399 shines compared to BCM2711 however, is regarding I/O bandwidth and memory bandwidth, even despite some DDR scheduling problems that sometimes show two A53 cores working much faster than twice a single one, because you need to have at least two working for the DDR controller to switch frequency. That might have improved by now, I have not rechecked, but it was quite painful. And of course, RK3399 has crypto extensions (or should I say BCM2711 doesn’t have them since virtually all other implementations have them).

The RPi4 is not bad at all, it just suffers from a very limited DRAM bus and from abysmal I/O performance due to using SD only. Other than that the chip is quite decent and may in some cases deliver better performance that other over-heating RK3399 that would throttle faster.

1 Like
#10

Still You can try to cool it from other side of board, some heat is spreading there. Even small fan is usually better than bigger heatsink, there are many low profile blowers that can be installed near soc. the last option is heatpipe - that allows to put larger cooling element outside board and quite small heatpipe on needed component. Of course i haven’t seen Your project, but there are so many solutions for cooling that I’m sure You can try to redesign just that, also You can find some cheap parts to try from old laptops. Maybe carefully bend some heatpipes to desired shape and if it’s not broken then it will be most efficient cooling with not much space taken near soc.
There are other rock4 version with soc on other side, for now only this one is available in okdo, but there are more in allnet.

1 Like
#11

Sure. Me as well. But I wasn’t talking about the SoC design but the ‘insights’ were around PVTM. Radxa currently does not provide OS images for Rock 4SE but encourages to use those for Rock 4B. And PVTM (or maybe another mechanism checking SoC ID or whatever) then decides to limit DVFS OPP to 1.5/1.0 GHz when RK3399-T is detected.

As for the throttling I remembered doing my heatsink tests few years ago with only RK3399 boards. And with insufficient cooling (heatsink attached but cramped into a tiny space w/o any air flow) throttling is to be expected. So this might not be a RK3399-T special but applies to RK3399 in general.

1 Like
#12

AFAIK they give clear specs about that board with 1.5GHz for SOC and up to 2.2GHz for other rock4 variants. Maybe they are different by design and something else requires to hold soc on this frequency? Of course maybe it can be overclocked with right cooling, but yes - if its higher than specs then it’s overclocking.

…
or it is just same thing with different settings because of marketing? :slight_smile: We also saw such things :wink:

1 Like
#13

Huh? I’ve neither talked about marketing nor specs but a mechanism called PVTM that just works with Rockchip’s BSP kernel and is ignored with mainline.

If an OS image for Rock 4B running on the RK3399-T equipped Rock 4SE ends up with the CPU cores automagically being limited to rather low clockspeeds how should marketing or specs be involved?

And whether those RK3399-T can work reliably at higher clockspeeds or not and what might be involved to get them run reliably (probably higher supply voltages resulting in even more heat and consumption) is also a totally different question I’m not even interested in :slight_smile:

1 Like
#14

I modified the sbc-bench.sh with:

export MODE=extensive
echo -n "MODE: " ; echo $MODE

and ran with sudo ./sbc-bench.sh

Results at: http://ix.io/4dLD

| ROCK PI 4B | 1512/1008 MHz | 4.4 | Ubuntu 20.04.5 LTS arm64 | 4860 | 228900 | 852950 | 3400 | 8240 | 7.97 |

One thing to mention - RadxaYuntian suggested:

that I should use the images listed under the SE column on the downloads wiki (which is an August 2022 image), but that was after I had found and configured this Oct 2022 image. So these sbc-bench results are not on a “blessed” SE image.

#15

The OPP tables look pretty much similar to what other board makers use, e.g. https://github.com/ThomasKaiser/sbc-bench/blob/master/results/opp-tables/rk3399-4.4.211-FriendlyElec_NanoPi_M4.txt

So at least not higher supply voltages for RK3399-T but maybe some MCU inside the SoC decides differently.

As for the RK3399-T being limited to 1.5/1.0 GHz most probably by switching to other images (that ignore the PVTM mechanism) you’re at higher clockspeeds. Whether this works reliably or not and you end up with lower performance as real result (caused by thermal throttling) is a different story :slight_smile:

1 Like
#16

BTW: so far I only found two other ARMv8 SoCs w/o Crypto Extensions leaving all the RPi Broadcom stuff aside: Amlogic S905 (ODROID-C2 and NanoPi K2) and Qualcomm MSM8916/APQ8016 (Snapdragon 410/412).