Orion O6 Debug Party Invitation

#21

More benchmarks are slowly popping up https://browser.geekbench.com/v6/cpu/9535176
“Model Cix Technology Group Co., Ltd. CIX AI PC”
1209
Single-Core Score

6052
Multi-Core Score

Too bad Geekbench doesn’t report which kernel was used etc.

1 Like
#22

Linux 6.6.10-cix-build-generic aarch64

https://browser.geekbench.com/v6/cpu/9535176.gb6

1 Like
#23

Looks like a downstream kernel then :confused:
Let’s see how it is in the end

#24

@hipboi explained CIX kernel roadmap over here.

And by looking at the available scores (and the metadata using the ’.gb6 trick’) we can expect that the scores will improve (most likely a lot): https://browser.geekbench.com/search?q=cix

Unfortunately Geekbench 6 is crap for ‘measuring’ multi-threaded performance and by not measuring memory bandwidth and latency we always have exactly no idea why the scores are as they are. In SoC bring-up stage often something goes wrong with DRAM initialization and then benchmark scores will drop by a large margin.

3 Likes
#25

Yep. The file compression test at least shows MB/s and what we can see is that in the MT test it delivers twice the performance of Rock 5B+, which is quite decent. Also such tools are never able to measure the performance on big cores only (or by excluding the little cores cluster which is not there for performance purposes). This would significantly help and even stabilize measurements: it’s even possible that some tests are not finishing at the same time on all cores and affect the overall measurement!

2 Likes
#26

Long time (20y+) linux user/sys admin/network admin here that would love to hack on general Debian support as well as testing various NICs with this board and isn’t afraid to use an SPI Flasher and recompile some kernels. I would also try to get DPDK/VPP up and running and do some benchmarks.

1 Like
#27

BredOS developer here, we develop an archlinux based os for many SBCs, we think BredOS supporting the Orion O6 would be good since there’s already a thread called “Archlinux for the Orion O6”

2 Likes
#28

I mainly work on development related to the Linux kernel and DRM. If I have a O6, I might be able to help with some display upstream-related work.

3 Likes
#29

The day has come ;D

Looking forward to see code while waiting for benchmarks and reviews.

#30

Here is the output from running sbc-bench: https://0x0.st/8opg.bin

4 Likes
Upcoming ARM v9 product with 45 TOPS NPU
#31

Thank you Naoki. I’m very pleased to see that it looks pretty good out of the box, with measured CPU frequencies matching the advertised OPP, and excellent RAM timings for tests from the A720 cores! The CPU cores ordering is very strange however, I don’t know if it’s caused by the cores declaration in the DTB or any such thing:

     CPU    cluster  policy   speed  speed   core type
      0        0        0      800    2500   Cortex-A720 / r0p1
      1        0        1      800    1800   Cortex-A520 / r0p1
      2        0        1      800    1800   Cortex-A520 / r0p1
      3        0        1      800    1800   Cortex-A520 / r0p1
      4        0        1      800    1800   Cortex-A520 / r0p1
      5        0        5      800    2300   Cortex-A720 / r0p1
      6        0        5      800    2300   Cortex-A720 / r0p1
      7        0        7      800    2200   Cortex-A720 / r0p1
      8        0        7      800    2200   Cortex-A720 / r0p1
      9        0        9      800    2400   Cortex-A720 / r0p1
     10        0        9      800    2400   Cortex-A720 / r0p1
     11        0        9      800    2400   Cortex-A720 / r0p1

=> 1 2.5G big core, 4 1.8G small cores, 2 big 2.3G cores, 2 big 2.2G cores, 3 big 2.4G cores. That’s 5 different clusters, compared to the expected 3 clusters which should be each made of 4 identical cores.
Regardless, despite the many different frequencies, these frequencies are reasonably good already (which explains the performance gains you measured on the kernel build).

In fact, I suspect that for the little cores (A520), where the DRAM timings are particularly bad, that’s exactly the same issue as on the rock5 where the DMC doesn’t leave powersave mode when only little cores are running, and very likely that the timings will be better if you change the DMC to performance mode. But for tests involving all cores at once, it should not change anything, since the big cores will turn the DMC to high performance mode anyway. On the rock5, running this significantly improves the little cores performance for me:

echo performance > /sys/devices/platform/dmc/devfreq/dmc/governor

I suspect you’ll see the same here. But again it will only affect workloads running exclusively on small cores, so nothing very important for your general tests.

1 Like
#32

I would call it smart since this device is supposed to run with ‘standard’ aarch64 OS images that lack any optimization wrt IRQ/SMP affinity as such making cpu0 the most beefy one makes a lot of sense. Though this ‘5 cluster’ setup is challenging to be properly monitored when hacking around with settings.

At least all A720 cores have the same cache size regardless of their current clockspeed differences.

Also I saw that Radxa has packaged irqbalanced to be included in their reference OS image as such good luck with stuff like network performance when IRQs get spread across the little cores.

BTW: I’ve bought a RTL8126 and two RTL8157 and do some 5GbE testing right now in preparation of hacking around with the two RTL8126 on O6. Asides iperf3 would you suggest better networking tests?

@hrw: /proc/cpuinfo for you https://0x0.st/8o9l.txt :slight_smile:

1 Like
#33

Looks like I am out of excuses and will have to order one. The only decisions to make are:

  • when to order (do not want to get call from courier while on vacations)
  • which ram size (SBC use: 16GB, desktop use: 32GB or devel use: 64GB)

CD8180 added to AArch64 SoC features table.

2 Likes