ThomasKaiser
commented
7 months ago Radxa put a Rock-5-ITX and a Rock 5C Lite (RK3582 with some SoC cores disabled) in the mail. Interestingly idle consumption with 5C Lite is slightly higher than on my 5B (with same RPi USB-C power brick on same Netio powermeter):
root@rock-5c:/home/radxa# Netio=192.168.83.72/4 sbc-bench.sh -m
Power monitoring on socket 4 of powerbox-1 (Netio 4KF, FW v3.2.0, XML API v2.4, 235.23V @ 50.02Hz)
Rockchip RK3582 / 35 82 12 fe 21 41 32 47 41 31 00 00 00 00, Kernel: aarch64, Userland: arm64
CPU sysfs topology (clusters, cpufreq members, clockspeeds)
cpufreq min max
CPU cluster policy speed speed core type
0 0 0 408 1800 Cortex-A55 / r2p0
1 0 0 408 1800 Cortex-A55 / r2p0
2 0 0 408 1800 Cortex-A55 / r2p0
3 0 0 408 1800 Cortex-A55 / r2p0
4 1 4 408 2400 Cortex-A76 / r4p0
5 1 4 408 2400 Cortex-A76 / r4p0
Thermal source: /sys/devices/virtual/thermal/thermal_zone0/ (soc-thermal)
Time big.LITTLE load %cpu %sys %usr %nice %io %irq Temp mW
20:28:01: 408/ 600MHz 0.06 1% 1% 0% 0% 0% 0% 34.2°C 1640
20:28:06: 408/1800MHz 0.06 2% 1% 0% 0% 0% 0% 35.2°C 1640
20:28:11: 408/ 600MHz 0.05 0% 0% 0% 0% 0% 0% 35.2°C 1630
20:28:16: 408/ 600MHz 0.05 1% 1% 0% 0% 0% 0% 35.2°C 1630
20:28:21: 408/ 600MHz 0.04 1% 1% 0% 0% 0% 0% 34.2°C 1640
20:28:26: 600/ 600MHz 0.12 2% 1% 0% 0% 0% 0% 35.2°C 1660
20:28:31: 408/ 600MHz 0.11 1% 0% 0% 0% 0% 0% 35.2°C 1670
20:28:37: 408/ 600MHz 0.10 1% 1% 0% 0% 0% 0% 35.2°C 1660
20:28:42: 408/ 600MHz 0.09 2% 1% 0% 0% 0% 0% 35.2°C 1680
20:28:47: 408/1800MHz 0.08 1% 0% 0% 0% 0% 0% 35.2°C 1690
20:28:52: 408/1800MHz 0.08 1% 0% 0% 0% 0% 0% 35.2°C 1700
20:28:57: 408/ 600MHz 0.07 1% 1% 0% 0% 0% 0% 35.2°C 1710
20:29:02: 408/ 408MHz 0.23 1% 1% 0% 0% 0% 0% 35.2°C 1720
20:29:07: 408/1800MHz 0.21 1% 1% 0% 0% 0% 0% 35.2°C 1720
20:29:13: 408/ 600MHz 0.19 1% 1% 0% 0% 0% 0% 35.2°C 1720And since you seem to have the RK3588S2 variant can you please post NVMEM contents from your board once you start testing?
For my RK3582 it looks like this:
root@rock-5c:/home/radxa# RK_NVMEM_FILE="$(find /sys/bus/nvmem/devices/rockchip*/* -name nvmem 2>/dev/null | head -n1)"
root@rock-5c:/home/radxa# hexdump -C <"${RK_NVMEM_FILE}"
00000000 52 4b 35 82 12 fe 21 41 32 47 41 31 00 00 00 00 |RK5...!A2GA1....|
00000010 00 00 00 00 18 15 04 07 07 09 20 0d 08 00 04 00 |.......... .....|
00000020 00 00 00 00 00 00 00 00 07 0a 00 00 00 c1 37 9b |..............7.|
00000030 4e e6 07 00 00 a2 06 b3 06 00 00 91 03 00 00 00 |N...............|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
geerlingguy
ginkage
cweickhmann
Altirix
Basic information
Linux/system information
Benchmark results
CPU
Power
stress-ng --matrix 0): 9.5 Wtop500HPL benchmark: 12.4 WDisk
Samsung Pro Plus 512GB A2 microSD card
Pinedrive 256GB 2242 NVMe via Pi 5 PCIe HAT
curl https://raw.githubusercontent.com/geerlingguy/pi-cluster/master/benchmarks/disk-benchmark.sh | sudo bashRun benchmark on any attached storage device (e.g. eMMC, microSD, NVMe, SATA) and add results under an additional heading. Download the script with
curl -o disk-benchmark.sh [URL_HERE]and runsudo DEVICE_UNDER_TEST=/dev/sda DEVICE_MOUNT_PATH=/mnt/sda1 ./disk-benchmark.sh(assuming the device issda).Also consider running PiBenchmarks.com script.
Network
iperf3results:iperf3 -c $SERVER_IP: 937 Mbpsiperf3 --reverse -c $SERVER_IP: 881 Mbpsiperf3 --bidir -c $SERVER_IP: 930 Mbps up, 419 Mbps down(Be sure to test all interfaces, noting any that are non-functional.)
GPU
glmark2-es2results:IMPORTANT NOTE: This test was run using the newest test release of Debian from Rockchip after the board was released. Apparently the GPU is better supported right now in Armbian builds with some custom patches applied. I have not run the board with that configuration yet, but it may be better to run Armbian if you want GPU acceleration.
TODO: See this issue for discussion about a full suite of standardized GPU benchmarks.
Memory
tinymembenchresults:Click to expand memory benchmark result
``` tinymembench v0.4.10 (simple benchmark for memory throughput and latency) ========================================================================== == Memory bandwidth tests == == == == Note 1: 1MB = 1000000 bytes == == Note 2: Results for 'copy' tests show how many bytes can be == == copied per second (adding together read and writen == == bytes would have provided twice higher numbers) == == Note 3: 2-pass copy means that we are using a small temporary buffer == == to first fetch data into it, and only then write it to the == == destination (source -> L1 cache, L1 cache -> destination) == == Note 4: If sample standard deviation exceeds 0.1%, it is shown in == == brackets == ========================================================================== C copy backwards : 12007.0 MB/s (2.9%) C copy backwards (32 byte blocks) : 11959.5 MB/s C copy backwards (64 byte blocks) : 11977.8 MB/s C copy : 12239.5 MB/s C copy prefetched (32 bytes step) : 12564.9 MB/s C copy prefetched (64 bytes step) : 12588.2 MB/s C 2-pass copy : 5405.8 MB/s (0.3%) C 2-pass copy prefetched (32 bytes step) : 9733.2 MB/s C 2-pass copy prefetched (64 bytes step) : 10402.0 MB/s C fill : 29606.2 MB/s (0.2%) C fill (shuffle within 16 byte blocks) : 29573.4 MB/s (0.2%) C fill (shuffle within 32 byte blocks) : 29646.4 MB/s (0.2%) C fill (shuffle within 64 byte blocks) : 29508.5 MB/s (0.2%) NEON 64x2 COPY : 12423.9 MB/s NEON 64x2x4 COPY : 12449.7 MB/s NEON 64x1x4_x2 COPY : 12495.1 MB/s NEON 64x2 COPY prefetch x2 : 11621.7 MB/s NEON 64x2x4 COPY prefetch x1 : 11957.2 MB/s NEON 64x2 COPY prefetch x1 : 11673.7 MB/s NEON 64x2x4 COPY prefetch x1 : 11954.6 MB/s --- standard memcpy : 12507.5 MB/s standard memset : 29477.5 MB/s --- NEON LDP/STP copy : 12537.3 MB/s NEON LDP/STP copy pldl2strm (32 bytes step) : 12434.3 MB/s NEON LDP/STP copy pldl2strm (64 bytes step) : 12462.2 MB/s NEON LDP/STP copy pldl1keep (32 bytes step) : 12568.9 MB/s NEON LDP/STP copy pldl1keep (64 bytes step) : 12571.8 MB/s NEON LD1/ST1 copy : 12451.5 MB/s NEON STP fill : 29455.0 MB/s (0.2%) NEON STNP fill : 29431.4 MB/s ARM LDP/STP copy : 12513.3 MB/s ARM STP fill : 29506.0 MB/s (0.2%) ARM STNP fill : 29458.7 MB/s ========================================================================== == Memory latency test == == == == Average time is measured for random memory accesses in the buffers == == of different sizes. The larger is the buffer, the more significant == == are relative contributions of TLB, L1/L2 cache misses and SDRAM == == accesses. For extremely large buffer sizes we are expecting to see == == page table walk with several requests to SDRAM for almost every == == memory access (though 64MiB is not nearly large enough to experience == == this effect to its fullest). == == == == Note 1: All the numbers are representing extra time, which needs to == == be added to L1 cache latency. The cycle timings for L1 cache == == latency can be usually found in the processor documentation. == == Note 2: Dual random read means that we are simultaneously performing == == two independent memory accesses at a time. In the case if == == the memory subsystem can't handle multiple outstanding == == requests, dual random read has the same timings as two == == single reads performed one after another. == ========================================================================== block size : single random read / dual random read 1024 : 0.0 ns / 0.0 ns 2048 : 0.0 ns / 0.0 ns 4096 : 0.0 ns / 0.0 ns 8192 : 0.0 ns / 0.0 ns 16384 : 0.0 ns / 0.0 ns 32768 : 0.0 ns / 0.0 ns 65536 : 0.0 ns / 0.0 ns 131072 : 1.1 ns / 1.5 ns 262144 : 2.2 ns / 2.8 ns 524288 : 3.5 ns / 4.0 ns 1048576 : 10.2 ns / 13.2 ns 2097152 : 14.0 ns / 15.9 ns 4194304 : 58.6 ns / 92.5 ns 8388608 : 142.7 ns / 198.5 ns 16777216 : 188.1 ns / 233.3 ns 33554432 : 212.1 ns / 245.3 ns 67108864 : 225.3 ns / 251.5 ns ```sbc-benchresultshttps://sprunge.us/5pv8oh
Phoronix Test Suite
Results from pi-general-benchmark.sh: