ROCK 5B Debug Party Invitation

#41

For the fellow reviewers/devs:

Radxa’s most recent OS images are here: https://github.com/radxa/debos-radxa/releases (two months ahead of where we should look at).

The eMMC has a compatible pin-out at least with Hardkernel and Pine64 (the second row of pins is just for better connection w/o any signals/power) so flashing one of these images with an eMMC-to-SD-card adapter was an easy one.

Default user/password: rock/rock

At least the rock-5b-ubuntu-focal-server-arm64-20220701-0826-gpt.img image has SSH enabled, fetches an IP address via DHCP and is good to go without connecting any display/peripherals except network:

root@rock-5b:/home/rock# sbc-bench.sh -m
Rockchip RK3588 (35880000), 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
  6        2        6      408    2400   Cortex-A76 / r4p0
  7        2        6      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
17:40:23:  408/1200MHz  0.11   0%   0%   0%   0%   0%   0%  30.5°C
17:40:28:  408/1008MHz  0.10   0%   0%   0%   0%   0%   0%  30.5°C
4 Likes
Introduce ROCK 5B - ARM Desktop level SBC
#42

First sbc-bench run: http://ix.io/41BH

Rock5B (and of course other RK3588 thingies) are so far the fastest SBC around (competition). And when comparing performance/watts most probably also the most power efficient (TBC).

Insights:

  • consumption with this set of benchmarks is really low: not exceeding 10W with the most demanding benchmarks (measured at wall with a NetIO ‘PowerCable REST 101F’ and an Apple 94W USB-C charger known for really low losses). Idle consumption with the Ubuntu Focal server image and network at GbE speeds: 3W.
  • CPU clockspeeds are controlled by an MCU inside the SoC (with this OS image A76 cores are clocking in at 2350 MHz instead of 2400 and A55 cores being clocked slightly higher). Also cpufreq governor gets ignored with RK’s BSP. Even with performance the MCU inside the SoC decides to downclock cores if they’ve nothing to do. Which is stuff for further inspection since it could negatively affect real-world workloads (talking Linux here and not Android).
  • There’s 3 CPU clusters: 4 x A55, 2 x A76, 2 x A76. The latter seem to behave the same but ofc they could be configured in different ways: cluster 2 way more aggressively jumping to higher DVFS OPP than cluster 1 and 0 to always allow for maximum single-threaded performance peaks. Again: this seems to be a closed sourced MCU thing if there is really a difference in behaviour of cluster 1 and 2 (both 2 x A76)
  • the supplied fansink is noisy/annoying but a) it does its job and b) Radxa will come up with something else for regular consumers (at least I hope so). Heatsink mounting holes are there and IIRC they’re designed for old x86 Northbridge coolers so there should be plenty of alternatives to the fansink provided with the 5B dev samples
  • memory performance is awesome. When testing the A55 cluster isolated (at 1820 MHz) it gets a 7-ZIP-MIPS score of ~5900 which is 20% ahead of other ARM SoCs featuring four A55 (also at 1.8-2.0 GHz)
5 Likes
#43

Was Radxa ROCK 5A a typo?

#44

I received mine as well and couldn’t resist running a few tests.

Man, this board is fast… amazingly fast! We’re seeing a great product come here.

Mine is configured to top at 2.304 GHz, I don’t know how Thomas got 2.400 in his tests. I noticed that the two A76 clusters don’t run at exactly the same frequency, cores 4 and 5 are reported as running at 2286-2290 MHz while cores 6 and 7 are measured at 2308 MHz. I suspect that something is disturbing cores 4-5 or maybe it’s someting internal, but quite frankly that’s a minor detail.

I could measure inter-core latency for atomic operations. It’s overall uniform across the 8 cores because they all share the same L3 cache, which is great. The values are excellent (27-28ns for R/O accesses, 56ns for A55 to anything, 67ns for A76-A76) and much better than the last Xeons I tested.

I have also run my usual build test. The build times are the shortest I’ve seen to date on this test, x86 included, and they’re twice as fast as the Odroid-N2+ at 2.4 GHz, which was the previous winner ( http://wiki.ant-computing.com/Choosing_a_processor_for_a_build_farm ).

As Thomas also noticed, the memory performance is excellent, and definitely participates to the very high build speed (since gcc is extremely sensitive to both latency and bandwidth). Having 4 channels very likely maintains low latencies even when all cores are loaded.

I also noticed that an extlinux.conf is used to pass the kernel parameters. Thanks for that! It’s so much easier than having to figure how to fiddle with a boot_param variable in a u-boot environment!

Oh and by the way, the board doesn’t particularly heat up during build sessions, so it seems like great components were chosen.

I noticed two small problems on the hardware layout though, that were already suspected from the photos. The holes for the heat sink not being centered around the SoC make it almost not touch the SoC (I’ll try to upload photos). This can certainly be arranged by placing something as high as the SoC at the opposite side. The second problem is the location of the heat shink hole that goes directly under the M.2 location. The plastic part is particularly high and I think it will cause trouble with some M.2 boards, though with flat screws it shouldn’t be a problem.

3 Likes
#45

IMG_1267cs
IMG_1267cs.JPG800×309 65.1 KB
IMG_1266cs
IMG_1266cs.JPG800×498 128 KB
IMG_1261cs
IMG_1261cs.JPG800×563 109 KB

From top to bottom:

  • the height of the plastic fixation for the fan compared to the M.2 connector.
  • how to connect a serial port while keeping the fan (use split wires and connect the ground to the next GND, one with a black color around the pin)
  • the heat sink as currently placed on the SoC. I’ll remove it and try other heat sinks and try to measure the most suitable riser needed to keep it perfectly flat.
3 Likes
#46

Wow that must be running cool if the heatsink is like that, but can not see it ever lying flat if its so far off centre?
If it does run so cool would they not be better reverting to the original smaller heatsink that also doesn’t protrude under the m.2?
PS the heat sink looks extremely close to the 1st row of gpio also.

1 Like
#47

And here comes a photo of the heat sink from my thermal IR camera under the exact same angle as above, with the fan unplugged during build loops (otherwise the temperature doesn’t raise in a relevant way).

We can see roughly 3 degrees difference between the SoC and the aluminum. Note that the measurement lacks accuracy due to using a small sensor, but it gives an idea. Overall it’s not bad at all, but definitely something that could be improved a bit :slight_smile:

IMG_1271cs
IMG_1271cs.JPG800×457 143 KB

2 Likes
#48

I think that by just adding a small washer or riser close to the HDMI connectors it will be sufficient. Also regarding the size of the plastic fixation, I don’t know what should be the final thermal solution, but if it’s just a heat sink, then there will likely be a flat screw on the other side and this shouldn’t be an issue. I’m bringing all observations here so that we don’t miss anything, but it doesn’t mean that I’m seeing serious problems at all.

I’m impatient to receive my M2->PCIe adapter to test the board at 10 Gbps :slight_smile:

1 Like
#49

You are right, things are generally improved by changing the thermal pad for a more efficient one.

But I can’t understand what happened between the development version RK3588_RS119_V1.0 of 09.11.2021
and the production version ROCK 5B V1.3 of 19.05.2022.
It started so well …

Seriously, when I see the benchmark, I think this thing should take a place in a HDD/Pico-Itx slot of my Helios64,
instead of all that, I think it’s a sign that this card isn’t ready yet,
and it would be a disservice this SOC to fixed us on something so visible and previsible.
considering the location of the holes, I have no idea how Radxa is going to put the keel :slight_smile:

I look forward to reading you for the rest !

#50

“the supplied fansink is noisy/annoying but a) it does its job and b) Radxa will come up with something else for regular consumers (at least I hope so).”

Yes, for the developer edition, we just grabbed some heatsink/fan from Starfive VisionFive, the connector doesn’t even match the PWM fan header on the 5b board.

3 Likes
#51

I don’t think its the fan that is the real problem in the long run, as if you draw a diagonal from the mounting holes that is where the pressure point and fulcrum will be. You could be offset a little, but when so far and crossing the very corner of the raised part of the cpu its going to do what its doing and at the least compression is going to be uneven.
Seems a little back to school with fulcrums and levers and Mr Archimedes…

I can understand why as there is very little room elsewhere but with the cpu shifting up that diagonal style mount isn’t going to be a great solution as the CPU on the board has moved up the board since the 1st revision.
Its a square peg and 2 round holes to me and can see why as there isn’t a whole lot of space for anywhere else and maybe it will have to be the spider type that presses down from mounted pillars on the normal board mounts.
Pretty sure you can find a better fan but also the fan connector is PWM so on 5v its going 100%?

1 Like
#52
1 Like
#53

That was my expectation as well, but thanks for confirming. I’ll eventually try to run some tests with various heat sinks.

1 Like
#54

I’ll try with diverse heat sinks, I have plenty here.

#55

Regarding power usage, here’s what I’m seeing, powered from 5V: 1.6W idle, 8.6W during a compilation, add one watt for the fan.

I also started it with a USB-C power block that I’m using for my laptop at home, and it boots fine but at the end of the boot sequence the machine stops and restarts. I’m suspecting it could have something to do with OTG initialization that might possibly cause the board to stop requesting power for a short instant, but I could of course be wrong. I’ll eventually try with other PSUs.

Edit: It’s indeed related to software, as it does so when I boot from the ubuntu image on the SD, but not from the debian image on the eMMC.

#56

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?

1 Like
#57

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.

rXCxqp
graph.rXCxqp.png900×450 17.5 KB

RYrKFS
graph.RYrKFS.png900×450 18.5 KB

4 Likes
#58

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.

#59

Gents, we are interested to hear about stability, wi-fi, ethernet, hdmi, nvme, usb and etc.

1 Like
#60

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.