ROCK 3B ideas and discussion

#102

Yes that’s clearly visible in these pathetic results… How do you want non-technical end-users not to be confused with such a mess! The irrelevance of this test is blatant in every report it seems.

It’s amazing that it can take that long to report so misleading results. Reading from /dev/urandom would be faster.

Be careful with this, sometimes it can take ages to take a CPU off, or you may even freeze some devices due to IRQ pinning. At least you should have it as a manual option such as “–geekbench-incorrect-cpu-workaround” or something evocative like this.

The strange variations with offline CPUs might be caused by some tests involving non-CPU stuff and relying on I/O that are now processed on remaining CPUs (which would indicate another lack of control of general activity in this test).

#103

For now I’m happy with this:

root@rock-5b:/home/tk# sbc-bench -G

sbc-bench v0.9.8 taking care of Geekbench

Installing needed tools: Done.
Checking cpufreq OPP. Done.
Executing RAM latency tester. Done.
Executing Geekbench. Done.
Checking cpufreq OPP. Done (22 minutes elapsed).

First run:

   Single-Core Score     578                 
   Crypto Score          764                 
   Integer Score         564                 
   Floating Point Score  576                 
   
   Multi-Core Score      2484               
   Crypto Score          3387               
   Integer Score         2373               
   Floating Point Score  2574               

Second run:

   Single-Core Score     578                 
   Crypto Score          792                 
   Integer Score         563                 
   Floating Point Score  576                 
   
   Multi-Core Score      2468               
   Crypto Score          3412               
   Integer Score         2345               
   Floating Point Score  2577               

   https://browser.geekbench.com/v5/cpu/compare/16890216?baseline=16890257

Full results uploaded to http://ix.io/48KU.

As such sending cpu0 offline while testing the big cores. Works on an idle system :slight_smile:

Results variation is still too high when checking the comparison. At least this operation mode refuses to ‘benchmark’ if average load is above 0.10 or CPU utilization is too high.

Majority of garbage results on Geekbench browser most probably suffers from background activity being too high.

And this won’t change. Those kitchen-sink benchmarking companies and HW vendors sit in the same boat: fooling consumers.

#104

Impressive to see up to 8% variations on some tests run twice on the same machine, and even 4% for just AES in single core which, by definition, ought to be ultra-stable! It tells a lot about the stabilization phase of the test!

When you think that some people use that to measure the effect of tuning some knobs :slight_smile:

This makes me think, another thing you could do before running this garbage test would be to disable swap (since a benchmark on a swapping system is nuts), and flush all caches. This could reduce the noise between measurements.

#105

It gets even better: https://browser.geekbench.com/v5/cpu/compare/16898883?baseline=16898962

I guess there really is some sort of random number generator integrated in Geekbench since how would you explain the ‘Navigation’ score difference?

As for swapping: this is handled by monitoring (checking prior and after benchmark device utilisation and also monitoring %sys and %iowait. At least on my Rock 5B no swapping happens and you can’t use Geekbench on boards with less than 2 GB anyway. On one of my NEO4 with just 1 GB of RAM only the A72 cluster test (with just 2 parallel threads) finishes without being oom-killed.

#106

It can come from anything, including starting a browser that occasionally checks for updates or is sensitive to network responsiveness. That’s exactly the type of metric that should be excluded from a benchmark.

Regarding swapping, OK if you monitor it. But my point is that some users could have a browser started in the background and that could cause swapping to happen. Anyway, there’s already so much randomness in these tests that I’m sure you’ll get some funny reports :wink:

#107

Geekbench is also very sensitive to lib versions.

When upgrading Rock 5B from Ubuntu Focal to Ubuntu Jammy guess what happens? According to Creepbench the board got around 10% slower :rofl:

Three times tested and the results all hint at the same fact: you can’t use Geekbench for benchmarking :slight_smile:

EDIT: When comparing the Jammy (Armbian) image with Radxa’s Ubuntu other benchmarks also perform worse (e.g. 7-zip 11% slower):

Distro Clockspeed Kernel 7-zip AES-128 (16 byte) AES-256 (16 KB) memcpy memset
Focal arm64 2350/1830 MHz 5.10 16450 683350 1337540 10830 29220
Jammy arm64 2350/1830 MHz 5.10 14660 665420 1339710 10230 29240

And the reason is simple: with the Armbian Jammy image memory latency is twice as high as with Radxa’s Ubuntu. That’s why sbc-bench contains both tinymembench and ramlat numbers (the latter also in Geekbench babysitting mode). See http://ix.io/48OL vs. http://ix.io/48PC

1 Like
#108

And some ‘reverse engineering’ about what Geekbench is actually doing with the individual tests:

This is Rk3568 vs. the little cluster of RK3588 so these are the same:

  • amount and kind of cores (4 x RK’s Cortex-A55 / r2p0)
  • exact same kernel (RK’s 5.10.66 BSP mess)
  • exact same OS (libs, compiler version)

What differs is this:

  • clockspeeds: the RK3568 clocks in at 1905 MHz and the A55 in my RK3588 at 1830 MHz
  • memory controller: RK3588’s being way more advanced/faster
  • different process node but that shouldn’t matter that much
  • maybe different cache sizes, I’ve not looked into ramlat results so far

https://browser.geekbench.com/v5/cpu/compare/16904879?baseline=16902213

#109

Wow memory latency got doubled, that’s a big concern. Maybe the DDR setup code in the SPL packaged with the bootloader changed between these two images.

#110

Yep. And the only one to blame is me.

It must be using the more recent rk3588_bl31_v1.26.elf some time ago that led to doubled memory latency. I had the time to rebuild an Armbian Focal image just now from scratch (that uses rk3588_bl31_v1.25.elf just like Radxa’s own images) and results are the same (within Geekbench’s results variation) as Radxa’s.

1 Like
#111

Good to know that this one must not be used! Anyway it proves once more (if it was needed at all) that all those micro-measurements like CPU and RAM are useful hints to spot what’s wrong on a system. I remember facing a problem on early RK3399 where the DDR was running at 200 MHZ by default on the BSP kernel! It was not exactly fast :slight_smile: . Spotting 500-600ns access times quickly drove me to the conclusion that something was totally wrong over there.

#112

ROCK 3B is finally available now after two years. Available now from Arace:

2 Likes
#113

Looks great :slight_smile: this seems to be solid RK3568 board with interesting features and great pico itx format. Also I think that pi5 set up new standard for boards, the one about designed, fitted active cooling as well as external uart/debug pins. So far it was sometimes included on several boards, but now this should be more and more important. Are there any cases and radiators for thus board?

#114

Love it, and pricing feels right!

1 Like
#115

Edit: I found more precise info about wired interfaces, seems that E slot is SDIO/uart/usb type, requiring specific wifi cards. But I also found interesting note about this board - it has 40 pin LVDS connection support. Some time ago I checked if anything from radxa has LVDS and there were only some very old boards. There are some boards with RK3566 with LVDS, RK3588 should also support that. I have several 1280x800 ips lvds panels and looking for something that can connect to that, should 3B do that?

#116

Do you have more info about the connector pinout?
I still have an 18.4" panel with dual channel 8-bit and TS (resistive) from the cubieboard 2 era and would like to know if could be used.

#117

Not much than this :frowning:
maybe @radxa will share more, because so far there is only LVDS mentioned in one of featuring images.

I also still have plenty of IPS panels based on LVDS and looking for something to skip controller boards and use them directly. ROCK 3B is based on quite old now RK3568 that still has LVDS support, which seems to be replaced by newer eDP connection.

LVDS may be also very interesting for those who want to harvest some old panel from laptops, those are very very cheap today.

#118

True.

Brand new (without touch):
18.4" eDP panel … $165.00 (3840x2160)
18.4" LVDS panel … $65.00 (1920x1080 FHD)

I think it will be difficult to find a cable for LVDS if you are a computer hobbyist.

#119

I think after kernel 5.15, eDP panel can be plugged and play without specific timing configuration if the pinout is correct. The eDP panel pinout and connector are very standard with 40P 0.5mm 4-lane for 4K or 30P 0.5mm 2-lane for FHD.

2 Likes
#120

The ROCK 3B E key supports PCIe + USB + SDIO + UART, so it can support WiFi 5 cards as well as old SDIO WiFi cards.

2 Likes