I don’t think it will matter willy as the mount point positions to the cpu position will always remain the same so likely any heatsink will have a pressure point balancing on that corner.
You might get some that are a bit better but thinking its always going to have a tendency to lift at the other side.
The thermal pad might even be making things worse?
ROCK 5B Debug Party Invitation
1 Like
Some performance/efficiency measurements made using 7z b walking through all DVFS OPP…
Why using 7-ZIP’s internal benchmark mode? https://github.com/ThomasKaiser/sbc-bench#7-zip
Rock 5B: idle temperature: 30.5°C, idle consumption: 3280mW (measured via PowerBOX 4KF with an Apple 94W USB-C charger)
single A55 core running 7-ZIP benchmark:
Sysfs/Tested: MIPS / Temp / Watt
408 / 400 : 380 30.5°C 3463mW
600 / 600 : 566 31.2°C 3443mW
816 / 850 : 798 31.5°C 3480mW
1008 / 1070 : 988 31.8°C 3566mW
1200 / 1240 : 1134 31.5°C 3570mW
1416 / 1430 : 1295 32.1°C 3666mW
1608 / 1650 : 1478 32.4°C 3776mW
1800 / 1840 : 1629 32.7°C 3880mW
single A76 core running 7-ZIP benchmark:
Sysfs/Tested: MIPS / Temp / Watt
408 / 400 : 652 31.5°C 3520mW
600 / 600 : 932 31.5°C 3633mW
816 / 860 : 1260 31.8°C 3670mW
1008 / 1060 : 1502 32.1°C 3730mW
1200 / 1260 : 1724 32.4°C 3776mW
1416 / 1440 : 1907 32.4°C 3766mW
1608 / 1630 : 2094 32.4°C 3876mW
1800 / 1820 : 2272 33.3°C 3980mW
2016 / 2020 : 2460 33.9°C 4130mW
2208 / 2190 : 2615 34.2°C 4333mW
2400 / 2350 : 2746 35.2°C 4590mW
As expected the higher DVFS OPP for the A76 core become more inefficient especially above 2.0 GHz.
4 Likes
I think we don’t need to insist on it, it was predictable since the presentation of the new version, and Radxa is measuring the problem.
I don’t know the exact heights of the components, personally I have several thicknesses of Gelid thermal pad solution, so it’s not really a problem for me with this configuration, moreover my case is ventilated with 12cm inaudible fan so I won’t use 40XX fan which makes 28db in continuous or 30XX or 20XX.
It is necessary for the Alpha to check that all promises can be kept in future developments for this motherboard, that there are no hidden flaws in the hardware engineering, you must push in this direction.
Because when Radxa starts distribution to the end user, matters are going to get complicated.
At the first visible design flaw, some people will cry for their money, and spit on the company forgetting the main thing, this card works and can bring a lot of satisfaction and the community will be divided.
Gents, we are interested to hear about stability, wi-fi, ethernet, hdmi, nvme, usb and etc.
1 Like
Regarding this, my board is currently up and running at home while I’m at work. I’ll run some ethernet performance tests later this week. I also have a USB SSD delivering 300-350 MB/s depending on the board it’s plugged on, I’ll have to test it with it.
Stability wise, I don’t have much to say in its current form, as the board doesn’t heat at all and is perfectly stable. I’ll rather run such tests with a fanless heatsink and try to spot the temperature limits above which trouble starts to appear.
In comparison another recent Rockchip SBC: NanoPi R5S (RK3568 based and as such comparable to Rock 3A): idle temperature: 32.5°C, idle consumption: 2740mW (measured via same PowerBOX and 15W RPi USB-C charger).
RK3568 features exactly same cores (4 x Cortex-A55 / r2p0) and the device is running exactly same kernel with same relevant settings (Rockchip’s 5.10.66 BSP kernel with CONFIG_HZ=300) and exactly same userland (Focal Fossa arm64) so we’re seeing here the difference memory access and process node makes (RK3588 made in a much more advanced and expensive process).
Sysfs/Tested: MIPS / Temp / Watt
408 / 410 : 336 37.6°C 3133mW
600 / 600 : 486 40.0°C 3243mW
816 / 820 : 651 41.0°C 3286mW
1104 / 1160 : 895 41.9°C 3410mW
1416 / 1480 : 1112 43.1°C 3510mW
1608 / 1680 : 1277 44.2°C 3663mW
1800 / 1840 : 1378 45.2°C 3773mW
1992 / 1940 : 1428 45.9°C 3800mW
The A55 in RK3588 at 400 MHz achieves an 380 7-ZIP MIPS score at a relative consumption of just 180 mW (3463-3280). The A55 in RK3568 scores only 336 at 390 mW (3133-2740). Higher memory latency resulting in lower ‘overall performance’ and worse process node in way higher consumption at the same time:
RK3588 RK3568
MHz MIPS / mW MIPS / mW
~405 380 / 183 336 / 393
600 566 / 163 486 / 503
~855 798 / 200 651 / 546
~1455 1295 / 386 1112 / 770
~1665 1478 / 496 1277 / 923
1840 1629 / 600 1378 / 1033
1 Like
@tkaiser could you please show me the outputs of your cpufreq settings and opp ? Mine limits at 2304 MHz but I’m seeing the dtb expose 2352 and 2400, I don’t understand what’s preventing them from being usable, they’re not based on a boost and I’m not seeing any message at boot. It’s the same for both debian and ubuntu.
Here’s what I’m having:
# grep '' /sys/devices/system/cpu/cpufreq/policy4/*
/sys/devices/system/cpu/cpufreq/policy4/affected_cpus:4 5
/sys/devices/system/cpu/cpufreq/policy4/cpuinfo_cur_freq:408000
/sys/devices/system/cpu/cpufreq/policy4/cpuinfo_max_freq:2304000
/sys/devices/system/cpu/cpufreq/policy4/cpuinfo_min_freq:408000
/sys/devices/system/cpu/cpufreq/policy4/cpuinfo_transition_latency:324000
/sys/devices/system/cpu/cpufreq/policy4/related_cpus:4 5
/sys/devices/system/cpu/cpufreq/policy4/scaling_available_frequencies:408000 600000 816000 1008000 1200000 1416000 1608000 1800000 2016000 2208000 2304000
/sys/devices/system/cpu/cpufreq/policy4/scaling_available_governors:conservative ondemand userspace powersave performance schedutil
/sys/devices/system/cpu/cpufreq/policy4/scaling_cur_freq:408000
/sys/devices/system/cpu/cpufreq/policy4/scaling_driver:cpufreq-dt
/sys/devices/system/cpu/cpufreq/policy4/scaling_governor:schedutil
/sys/devices/system/cpu/cpufreq/policy4/scaling_max_freq:2304000
/sys/devices/system/cpu/cpufreq/policy4/scaling_min_freq:408000
/sys/devices/system/cpu/cpufreq/policy4/scaling_setspeed:<unsupported>
Though the DTB gives me this:
# dtc -I dtb -O dts < rk3588-rock-5b.dtb |less
...
...
cluster1-opp-table {
...
opp-2304000000 {
opp-supported-hw = <0xff 0x24>;
opp-hz = <0x00 0x89544000>;
opp-microvolt = <0xf4240 0xf4240 0xf4240 0xf4240 0xf4240 0xf4240>;
clock-latency-ns = <0x9c40>;
};
opp-2352000000 {
opp-supported-hw = <0xff 0x48>;
opp-hz = <0x00 0x8c30ac00>;
opp-microvolt = <0xf4240 0xf4240 0xf4240 0xf4240 0xf4240 0xf4240>;
clock-latency-ns = <0x9c40>;
};
opp-2400000000 {
opp-supported-hw = <0xff 0x80>;
opp-hz = <0x00 0x8f0d1800>;
opp-microvolt = <0xf4240 0xf4240 0xf4240 0xf4240 0xf4240 0xf4240>;
clock-latency-ns = <0x9c40>;
};
}
It’s obviously not dramatic, I’m just wondering why we’re seeing different behaviors.
Edit (since I cannot post anymore): There’s this “opp-supported-hw” field in the opp that lists values. I’m wondering if it’s relying on a CPU or board identifier (which could make sense, it’s possible that we have slightly different models since they’re early samples).
####### EDIT: Sorry for the mess below, but the forum refuses my new posts and asks me to wait 9 hours or to modify an existing post. That’s grossly stupid but I have no other solution #############
response to @tkaiser’s list of OPP below
Ah very interesting! I’m seeing this on mine:
# dmesg|grep cpu.*pvtm [ 2.606324] cpu cpu0: pvtm=1482 [ 2.606542] cpu cpu0: pvtm-volt-sel=3 [ 2.614206] cpu cpu4: pvtm=1722 [ 2.618389] cpu cpu4: pvtm-volt-sel=5 [ 2.626814] cpu cpu6: pvtm=1744 [ 2.630998] cpu cpu6: pvtm-volt-sel=6
Yours says:
[ 3.117399] cpu cpu0: pvtm=1528 [ 3.117491] cpu cpu0: pvtm-volt-sel=5 [ 3.124529] cpu cpu4: pvtm=1785 [ 3.128495] cpu cpu4: pvtm-volt-sel=7 [ 3.136234] cpu cpu6: pvtm=1782 [ 3.140173] cpu cpu6: pvtm-volt-sel=7
And mine has a lower measured frequency on CPU4 than CPU6 so it would very likely point in this direction.
Now I understand better the difference I was seeing between the measured performance of both clusters, I didn’t notice that the second one was indeed really slightly faster:
# grep '' /sys/devices/system/cpu/cpufreq/policy*/scaling_available_frequencies /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies:408000 600000 816000 1008000 1200000 1416000 1608000 1800000 /sys/devices/system/cpu/cpufreq/policy4/scaling_available_frequencies:408000 600000 816000 1008000 1200000 1416000 1608000 1800000 2016000 2208000 2304000 /sys/devices/system/cpu/cpufreq/policy6/scaling_available_frequencies:408000 600000 816000 1008000 1200000 1416000 1608000 1800000 2016000 2208000 2352000
So there’s something related to measured voltages. Note that this does happen both with a 12Vin PSU and a 5V one.
@hipboi could this have something to do with a possibly insufficient resistor divider precision in a voltage regulator circuit, or with one of these regs themselves ? I can measure the voltages if needed, I’m just unsure where to check as I cannot precisely identify the chip locations on the board. Just let me know if you’d like me to check certain things.
I would say by the look of things the mounting points to cpu are a flaw as think others can see that its just so much on a single corner of the cpu, its never going to be really great.
One thing though is the RK3588 runs really cool and think it has took some by surprise how cool.
I didn’t realise it was a tri cluster like some of the current top of the range socs with the newer Xcores, mid core and then the little.
It will prob play havoc with many benchmarks for single core as likely a wrong core will be chosen for bench.
But this is a Dev sample and a pre-release so nothing is set in stone as of yet and what pre-release samples are for.
The fan noise is because its running @ 100% on the wrong header as the fan is a dupont with the wrong type of header for the onboard PWM fan control (Its is a 5v fan on 5v yeah?).
Even the mounting holes might not be much of a thing as it could necessitate a custom heatsink that has sprung legs spidering out to the board mounts.
The heatsink/fan is an extra so if more needs to be done and charged then it doesn’t effect the Rock5b base price.
@willy what temps are you getting as with the 7zip @ 2400 @tkaiser is only getting 35.2°C and generally his temps are extremely low generally that sort of range is often idle temps not a stress test 
Sure:
root@rock-5b:~# ls -ld /proc/device-tree/cluster0-opp-table/opp-*
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster0-opp-table/opp-1008000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster0-opp-table/opp-1200000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster0-opp-table/opp-1416000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster0-opp-table/opp-1608000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster0-opp-table/opp-1800000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster0-opp-table/opp-408000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster0-opp-table/opp-600000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster0-opp-table/opp-816000000
-r--r--r-- 1 root root 0 Jul 5 09:43 /proc/device-tree/cluster0-opp-table/opp-shared
root@rock-5b:~# ls -ld /proc/device-tree/cluster1-opp-table/opp-*
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster1-opp-table/opp-1008000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster1-opp-table/opp-1200000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster1-opp-table/opp-1416000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster1-opp-table/opp-1608000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster1-opp-table/opp-1800000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster1-opp-table/opp-2016000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster1-opp-table/opp-2208000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster1-opp-table/opp-2256000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster1-opp-table/opp-2304000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster1-opp-table/opp-2352000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster1-opp-table/opp-2400000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster1-opp-table/opp-408000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster1-opp-table/opp-600000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster1-opp-table/opp-816000000
-r--r--r-- 1 root root 0 Jul 5 09:40 /proc/device-tree/cluster1-opp-table/opp-shared
root@rock-5b:~# ls -ld /proc/device-tree/cluster2-opp-table/opp-*
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster2-opp-table/opp-1008000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster2-opp-table/opp-1200000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster2-opp-table/opp-1416000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster2-opp-table/opp-1608000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster2-opp-table/opp-1800000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster2-opp-table/opp-2016000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster2-opp-table/opp-2208000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster2-opp-table/opp-2256000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster2-opp-table/opp-2304000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster2-opp-table/opp-2352000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster2-opp-table/opp-2400000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster2-opp-table/opp-408000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster2-opp-table/opp-600000000
drwxr-xr-x 2 root root 0 Jul 5 09:40 /proc/device-tree/cluster2-opp-table/opp-816000000
-r--r--r-- 1 root root 0 Jul 5 09:43 /proc/device-tree/cluster2-opp-table/opp-shared
root@rock-5b:~# grep '' /sys/devices/system/cpu/cpufreq/policy4/*
/sys/devices/system/cpu/cpufreq/policy4/affected_cpus:4 5
/sys/devices/system/cpu/cpufreq/policy4/cpuinfo_cur_freq:408000
/sys/devices/system/cpu/cpufreq/policy4/cpuinfo_max_freq:2400000
/sys/devices/system/cpu/cpufreq/policy4/cpuinfo_min_freq:408000
/sys/devices/system/cpu/cpufreq/policy4/cpuinfo_transition_latency:324000
/sys/devices/system/cpu/cpufreq/policy4/related_cpus:4 5
/sys/devices/system/cpu/cpufreq/policy4/scaling_available_frequencies:408000 600000 816000 1008000 1200000 1416000 1608000 1800000 2016000 2208000 2400000
/sys/devices/system/cpu/cpufreq/policy4/scaling_available_governors:conservative ondemand userspace powersave performance schedutil
/sys/devices/system/cpu/cpufreq/policy4/scaling_cur_freq:408000
/sys/devices/system/cpu/cpufreq/policy4/scaling_driver:cpufreq-dt
/sys/devices/system/cpu/cpufreq/policy4/scaling_governor:performance
/sys/devices/system/cpu/cpufreq/policy4/scaling_max_freq:408000
/sys/devices/system/cpu/cpufreq/policy4/scaling_min_freq:408000
/sys/devices/system/cpu/cpufreq/policy4/scaling_setspeed:<unsupported>
2304 for example is defined in DT but also missing from my list of available frequencies. So it seems there’s another place determining which freqs get activated and which not…
1 Like
I think the opp table is sort of bogus a bit like the amlogic where its the internal mcu blob that is really at work.
The temp you referred to was cearly labeled ‘single A76 core running 7-ZIP benchmark’, multi-threaded results were posted already yesterday.
The fansink on my board fits really tight, there’s an annoying fan spinning at maximum rpm and I operate my board upright standing to let convection jump in. And as you can see from the consumption measurements RK3588 is a different beast than the SoCs we were used to deal with in the past!
BTW: I really don’t get all this babbling polluting this thread. These are dev samples and Radxa guys looked into drawers and put something on that works. The final product will be shipped with a different heatsink anyway…
3 Likes
I don’t remember the measure but they were in that range as well. The CPU is barely warm when the fan spins. The CPU doesn’t consume much, which also explains why even with an uneven surface it still cools well.
Quite frankly, I’m not worried about this part at all. When you see the number of boards sold for which there are no holes at all, and which rely on you gluing the heatsink on top of the CPU, we already have more options there so let’s not turn this limitation into a big problem. It seems that there are little more options to place all components on that board anyway, so the CPU could hardly be more centered. Maybe one option could be to try to slightly rotate the heat sink by placing the holes differently but that’s not easy. I really think that just using a rubber pad of the same height at one extremity will completely solve the problem.
Stick on would do as that is another option with the temps your posting, did you find any other fans to stick on the real fan header. I have a few here but still waiting for delivery.
Its prob that thermal pad that has made things worse willy.
I am frankly uncomfortable asking
but can you swing the returns
cat /sys/kernel/debug/regulator/regulator_summary
cat /sys/kernel/debug/pinctrl/ * /gpio-ranges
cat /sys/kernel/debug/pinctrl/ * /pinmux-pins
cat /sys/kernel/debug/pinctrl/ * /pinmux-functions
cat /sys/kernel/debug/pinctrl/ * /pingroups
cat /sys/kernel/debug/pinctrl/ * /pinconf-pins
cat /sys/kernel/debug/pinctrl/ * /pinconf-groups
ou similar
I’m having a 16GB model with the following silkscreened on it: ‘2022.05.19 ROCK 5B V1.3’ (looks exactly like the pictures in 1st post of this thread except of RK3588 which is a different revision):
As a quick reference dmesg (only interesting stuff I found is around the hyst lines) and DTS from me.
2 Likes
root@rock-5b:/home/rock# ( cat /sys/kernel/debug/regulator/regulator_summary ; grep -R . /sys/kernel/debug/pinctrl/ ) | curl -s -F 'f:1=<-' ix.io
http://ix.io/41F1
BTW: grep -R . /sys/kernel/debug/ freezes the board
1 Like
Could you please confirm if PCI express indeed works at 3.0 version speeds?
Those devices with black metal case must be nanopi’s R5S or R6S.
R5S as mentioned above when comparing performance/consumption between RK3568 and RK3588.
I’m about to setup a nice 2.5GbE ‘LAN party’ with those 3 ARM boards and 2 MacBooks with RTL8156 dongles
BTW: never heard of R6S but there’s a little room for speculation about a soon to be announced NanoPi R3S (also based on RK3568).
OK, @willy (who can’t post here since registered just yesterday) pointed me in this direction:
R6S based on RK3588S