The ROCK Pi X is the first x86 SBC (single board computer) from Radxa and resulted from repeated enquiries about running Windows on their earlier ROCK Pi 4. The ROCK Pi X comes in two models (Model A and Model B) with each model having either 1GB, 2GB, or 4GB of RAM and either 16GB, 32GB, 64GB, or 128GB of eMMC storage. Additionally, the Model B includes WiFi and Bluetooth together with supporting Power over Ethernet (PoE) although this requires an additional HAT.
Both Seeed Studio and Radxa provided samples and in this review, I’ll cover some performance metrics from both Windows and Ubuntu and also discuss the thermals.
Rock Pi X Hardware Overview
The ROCK Pi X is similar in size to a Raspberry Pi board…
but with slightly different ports and port locations even when compared to the Raspberry Pi 4.
It is physically slightly larger than its specification size (85 mm x 54 mm) as the ports protrude from the board making it approximately 88 mm x 58 mm x 22 mm (3.46 x 2.28 x 0.87 inches). It uses Intel’s somewhat dated Atom (Cherry Trail) x5-Z8350 processor which is a quad-core 4-thread 1.44 GHz processor boosting to 1.92 GHz with Intel’s Gen8 HD graphics.
Both review units were Model B and came with 4GB of RAM soldered on. The Seeed Studio unit had 32GB of soldered eMMC whereas the Radxa unit had 128GB of soldered eMMC. On one end of each board are dual USB 2.0 ports, a further dual USB port stack but with the lower port being USB 3.0 whilst the top one is USB 2.0 and a gigabit Ethernet port. Then on one of the board’s longer sides is a headphone jack, an HDMI 2.0 port, and a Type-C USB port which is only for power. On the opposite side of the board is a 40-pin expansion header. Along the final side of the board is a micro-SD card slot and a power button with green and blue LEDs. Additionally, there is WiFi 5 (or 802.11ac) and Bluetooth 4.2.
The full specifications include:
The board comes in a plastic box:
and Model B includes a WiFi/Bluetooth antenna.
To power the board you need an external power adapter supplying 9V/2A, 12V/2A, 15V/2A, or 20V/2A. Also recommended is some form of cooling for the board and an aluminum heat sink kit is available for purchase. Radxa included both an 18W power adapter and the heat sink kit with their review unit:
When reviewing mini PCs I typically look at their performance under both Windows and Linux so I decided to review using a dual-boot of Windows 10 version 20H2 and Ubuntu 20.04 LTS point release 1 and test with a selection of commonly used Windows benchmarks and/or equivalents for Linux together with Thomas Kaiser’s ‘sbc-bench’ which is a small set of different CPU performance tests focusing on server performance when run on Ubuntu. Additionally, I used ‘Phoronix Test Suite’ to benchmark the same set of tests on both Windows and Ubuntu for comparison purposes. On Ubuntu, I also compile the v5.4 Linux kernel using the default config as a test of performance.
Prior to benchmarking, I perform all necessary installations and updates. I also capture some basic details of the device for each OS.
Rock Pi X Drivers Installation Issues
When Windows was installed using the latest ISO from Microsoft a number of drivers were missing:
Using a combination of drivers from the Radxa ‘Downloads’ page and Windows ‘Optional updates’ most of these could be resolved. For the Seeed Studio unit only a single Intel SD Host Controller remained without a driver:
However, during testing, the Ethernet port on this unit started to randomly disconnect before eventually stopping completely. Additionally, the 32GB of storage was severely limiting as I didn’t have sufficient space on Windows to run all my usual benchmarks. Installing Windows left only 4.5GB free:
which isn’t much for user applications and Windows updates.
I also observed excessive thermal CPU throttling as the board did not have any cooling. While discussing the Ethernet issue with Radxa they offered a replacement unit with 128GB storage and a heat sink together with an appropriate power supply.
Unfortunately after installing Windows on this replacement unit and updating all the drivers this time two ‘Generic SDIO Device’ had missing drivers and the ‘Nuvoton SST Nau88L24 Codec Device’ driver would not start:
and sometimes after a reboot, it fails in Windows:
However, the same Nuvoton device also had a problem in Ubuntu on this unit:
linuxium@ROCK-Pi-X:~$ dmesg | grep nau
[ 6.113332] nau8824 i2c-10508824:00: Failed to read device id from the NAU8824: -121
[ 6.113710] nau8824: probe of i2c-10508824:00 failed with error -121
[ 7.612340] cht-bsw-nau8824 cht-bsw-nau8824: ASoC: failed to init link SSP2-Codec: -517
[ 7.612350] cht-bsw-nau8824 cht-bsw-nau8824: snd_soc_register_card failed -517
[ 8.121645] cht-bsw-nau8824 cht-bsw-nau8824: ASoC: failed to init link SSP2-Codec: -517
[ 8.121654] cht-bsw-nau8824 cht-bsw-nau8824: snd_soc_register_card failed -517
[ 8.345592] cht-bsw-nau8824 cht-bsw-nau8824: ASoC: failed to init link SSP2-Codec: -517
[ 8.345602] cht-bsw-nau8824 cht-bsw-nau8824: snd_soc_register_card failed -517
and this resulted in the headphone jack not being recognized. Interestingly the driver did work in Ubuntu on the Seeed Studio unit:
Unfortunately, it didn’t work ‘OOTB’ and required a tedious workaround of installing ‘pavucontrol’, toggling the built-in audio from speaker to headphones, editing the UCM file ‘/usr/share/alsa/ucm2/chtnau8824/HiFi.conf’ to remove the ‘Speaker.conf’ entry, killing ‘pulseaudio’, and finally selecting multichannel output as the output device in the sound settings. To go back to HDMI audio required reverting these changes so I don’t see this as a very satisfactory solution even if Ubuntu does recognize the device.
It is also worth noting that after the BIOS upgrade each unit. whilst appearing identical based on the version of ‘Build Data and Time’ and other information displayed on screen in the BIOS ‘Main’ menu, is in fact slightly different including for example that the ‘Manufacturer’ is ‘Radxa’ on the Seeed Studio unit but ‘ROCK Pi’ on the Radxa unit. However, a more significant difference between the two units is that the version of the board is different as silk-screened on the Seeed Studio unit is ‘V1.4’ whereas it is ‘V1.3’ on the Radxa unit. This may account for why the Nuvoton device works in Ubuntu on one unit and not the other.
To get the WiFi to work on Windows the NVRAM file ‘4345r6nvram.txt’ from MINIX’s Z83-4 WiFi drivers had to be copied to ‘C:\Windows\System32\drivers’.
For Ubuntu, the WiFi and Bluetooth drivers were extracted from MINIX’s Ubuntu 20.04 LTS ISO and respun into an installable ISO using ‘isorespin.sh‘.
In Ubuntu a battery was detected:
so to the setting for automatic suspend when on battery power was switched to off.
There were also some issues related to the benchmarks. I could not successfully run ‘Cinebench’ in Windows as it crashed each time with an ‘Application Error’:
which seemed to point towards a memory issue:
OS_Type = WINDOWS 64 BIT
OS_Version = Windows 10, 64 Bit, Core (build 19042)
Number_of_processors = 4
Processor_Type = GenuineIntel, stepping 4, model 12, instruction family 6
Processor_Name = Intel Atom x5-Z8350 CPU
Processor_Speed = 1440 MHz
Processor_Features = FPU, MMX, SSE, RDTSC, CMPXCHG8B, CMOV, VME, DE, PSE, MSR, PAE, MCE, APIC, SEP, MTRR, PGE, MCA, PAT, PSE36, FXSR, SSE2, CLFLUSH, DS, SS, TM, SSE3, SSSE3, SSE4.1, SSE4.2, Enhanced SpeedStep, CMPXCHG16B, AES
Graphics_card = Vendor: Intel, renderer: Intel(R) HD Graphics 400, version: 3.2.0 - Build 220.127.116.1149 (18.104.22.16849)
Loaded_Plugins = advanced render ca cinebench colorchoosergui expressiontag mkmodeler model mograph nbp newman objects shader sky sla xpressocore xtensions
Active Scene: 0x000002112B1E1380 "C:\Program Files\CinebenchR20\resource\modules\cinebench\cpu\cpu.c4d"
ExceptionNumber = 0xC0000005
ExceptionText = "ACCESS_VIOLATION"
Address = 0x00007FFAE42CAE08
Thread = 0x0000000000001890
Last_Error = 0x00000000
Note that this error was seen on the Radxa unit as I didn’t attempt to run it on the Seeed Studio unit.
Additionally, Windows ‘blue screened’ a few times when running the benchmarks. It wasn’t clear whether this was related to the memory issue or due to thermal constraints which are further explained in the ‘Thermals’ section below.
One other point to note was that the ‘Selenium’ test from the ‘Phoronix Test Suite’ benchmarks refused to run the ‘Chrome’ option so the Octane tests had to be run manually and edited into the final results.
RockPi X Windows Benchmarks
Whilst I ran some benchmarks on the Seeed Studio unit the following results are for the Radxa unit fitted with the heat sink. The Radxa unit came installed with an unlicensed copy of Windows 10 Pro for Workstations version 1909 build 18363.900. Initially, I upgraded this to version 20H2 build 19042.685 and after believing everything to be working I decided to reinstall Windows version 20H2 using a downloaded Windows ISO and then upgrade to build 19042.685. The issues I encountered are noted above.
A quick look at the hardware information shows:
I had set the power mode to Best performance:
before running some benchmarking tools to look at Rock Pi X performance under Windows, including Passmark, PCMark 10, Novabench, 3Dmark, GeekBench, and others:
For my specific set of Phoronix Test Suite tests the results were:
All of the results can be compared with the MINIX NEO Z83-4 Plus which is a similar passively cooled mini PC with the same specification except for smaller storage:
and shows that the Radxa ROCK Pi X performance is as expected.
The Cherry Trail CPU coupled with its integrated graphics is not particularly powerful and not suitable for gaming.
Continuing the testing using the Radxa unit after shrinking the Windows partition in half and creating a new partition I installed my respun Ubuntu 20.04.1 ISO as dual boot. After installation and updates, the key hardware information is as follows:
linuxium@ROCK-Pi-X:~$ lsb_release -a
Distributor ID: Ubuntu
Description: Ubuntu 20.04.1 LTS
linuxium@ROCK-Pi-X:~$ uname -a
Linux ROCK-Pi-X 5.4.0-58-generic #64-Ubuntu SMP Wed Dec 9 08:16:25 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
linuxium@ROCK-Pi-X:~$ inxi -Fc0
System: Host: ROCK-Pi-X Kernel: 5.4.0-58-generic x86_64 bits: 64 Desktop: Gnome 3.36.4
Distro: Ubuntu 20.04.1 LTS (Focal Fossa)
Machine: Type: Desktop System: ROCK Pi product: ROCK Pi X v: N/A serial: N/A
Mobo: ROCK Pi model: ROCK Pi X v: 1.0 serial: N/A UEFI: American Megatrends v: 5.11 date: 09/24/2020
Battery: ID-1: axp288_fuel_gauge charge: 7% condition: N/A
CPU: Topology: Quad Core model: Intel Atom x5-Z8350 bits: 64 type: MCP L2 cache: 1024 KiB
Speed: 1181 MHz min/max: 480/1920 MHz Core speeds (MHz): 1: 1060 2: 480 3: 987 4: 1510
Graphics: Device-1: Intel Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Integrated Graphics driver: i915 v: kernel
Display: server: X.Org 1.20.8 driver: i915 resolution: 1920x1080~60Hz
OpenGL: renderer: Mesa DRI Intel HD Graphics (CHV) v: 4.6 Mesa 20.0.8
Audio: Device-1: Intel Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Imaging Unit driver: intel_atomisp2_pm
Sound Server: ALSA v: k5.4.0-58-generic
Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
IF: enp1s0 state: up speed: 1000 Mbps duplex: full mac: xx:xx:xx:xx:xx:xx
IF-ID-1: wlan0 state: down mac: xx:xx:xx:xx:xx:xx
Drives: Local Storage: total: 115.23 GiB used: 53.43 GiB (46.4%)
ID-1: /dev/mmcblk0 model: SLD128 size: 115.23 GiB
Partition: ID-1: / size: 56.16 GiB used: 15.82 GiB (28.2%) fs: ext4 dev: /dev/mmcblk0p5
Sensors: System Temperatures: cpu: 56.0 C mobo: N/A
Fan Speeds (RPM): N/A
Info: Processes: 215 Uptime: 5h 05m Memory: 3.77 GiB used: 830.8 MiB (21.5%) Shell: new.review-test inxi: 3.0.38
linuxium@ROCK-Pi-X:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 1.9G 0 1.9G 0% /dev
tmpfs 386M 1.9M 384M 1% /run
/dev/mmcblk0p5 57G 16G 38G 30% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
/dev/loop1 30M 30M 0 100% /snap/snapd/8542
/dev/loop0 55M 55M 0 100% /snap/core18/1880
/dev/loop3 63M 63M 0 100% /snap/gtk-common-themes/1506
/dev/loop4 50M 50M 0 100% /snap/snap-store/467
/dev/loop2 256M 256M 0 100% /snap/gnome-3-34-1804/36
/dev/mmcblk0p1 96M 33M 64M 35% /boot/efi
tmpfs 386M 40K 386M 1% /run/user/1000
/dev/mmcblk0p3 58G 38G 20G 66% /media/linuxium/98260DAD260D8D86
linuxium@ROCK-Pi-X:~$ lsblk -a
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 55M 1 loop /snap/core18/1880
loop1 7:1 0 29.9M 1 loop /snap/snapd/8542
loop2 7:2 0 255.6M 1 loop /snap/gnome-3-34-1804/36
loop3 7:3 0 62.1M 1 loop /snap/gtk-common-themes/1506
loop4 7:4 0 49.8M 1 loop /snap/snap-store/467
loop5 7:5 0 0 loop
loop6 7:6 0 0 loop
loop7 7:7 0 0 loop
mmcblk0 179:0 0 115.2G 0 disk
├─mmcblk0p1 179:1 0 100M 0 part /boot/efi
├─mmcblk0p2 179:2 0 16M 0 part
├─mmcblk0p3 179:3 0 57.3G 0 part /media/linuxium/98260DAD260D8D86
├─mmcblk0p4 179:4 0 505M 0 part
└─mmcblk0p5 179:5 0 57.3G 0 part /
mmcblk0boot0 179:8 0 4M 1 disk
mmcblk0boot1 179:16 0 4M 1 disk
linuxium@ROCK-Pi-X:~$ sudo lshw -C cpu
product: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz
vendor: Intel Corp.
physical id: 34
bus info: cpu@0
version: Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz
slot: SOCKET 0
width: 64 bits
capabilities: lm fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp x86-64 constant_tsc arch_perfmon pebs bts rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch epb pti ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm ida arat md_clear cpufreq
configuration: cores=4 enabledcores=4 threads=4
linuxium@ROCK-Pi-X:~$ sudo lshw -C memory
vendor: American Megatrends Inc.
physical id: 0
capabilities: pci upgrade shadowing cdboot bootselect socketedrom edd int13floppy1200 int13floppy720 int13floppy2880 int5printscreen int14serial int17printer acpi usb biosbootspecification uefi
description: System Memory
physical id: 28
slot: System board or motherboard
description: DIMM DDR3 1600 MHz (0.6 ns)
vendor: Hynix Semiconductor
physical id: 0
width: 8 bits
clock: 1600MHz (0.6ns)
description: DIMMProject-Id-Version: lshwReport-Msgid-Bugs-To: FULL NAME <EMAIL@ADDRESS>PO-Revision-Date: 2012-02-02 13:04+0000Last-Translator: Joel Addison <firstname.lastname@example.org>Language-Team: English (Australia) <en_AU@li.org>MIME-Version: 1.0Content-Type: text/plain; charset=UTF-8Content-Transfer-Encoding: 8bitX-Launchpad-Export-Date: 2020-07-09 17:42+0000X-Generator: Launchpad (build 4809fcb62f445aaa3ae919f7f6c3cc7d156ea57a) [empty]
vendor: Hynix Semiconductor
physical id: 1
description: L1 cache
physical id: 32
slot: CPU Internal L1
capabilities: internal write-back
description: L2 cache
physical id: 33
slot: CPU Internal L2
capabilities: internal write-back unified
linuxium@ROCK-Pi-X:~$ free -mh
total used free shared buff/cache available
Mem: 3.8Gi 622Mi 242Mi 120Mi 2.9Gi 2.8Gi
Swap: 2.0Gi 50Mi 2.0Gi
linuxium@ROCK-Pi-X:~$ sudo lshw -C network
description: Ethernet interface
product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
vendor: Realtek Semiconductor Co., Ltd.
physical id: 0
bus info: pci@0000:01:00.0
logical name: enp1s0
width: 64 bits
capabilities: pm msi pciexpress msix vpd bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=r8169 duplex=full firmware=rtl8168e-3_0.0.4 03/27/12 ip=xxx.xxx.xxx.xxx latency=0 link=yes multicast=yes port=MII speed=1Gbit/s
resources: irq:16 ioport:e000(size=256) memory:91804000-91804fff memory:91800000-91803fff
description: Wireless interface
physical id: 1
logical name: wlan0
capabilities: ethernet physical wireless
configuration: broadcast=yes driver=brcmfmac driverversion=7.45.18 firmware=01-6a2c8ad4 multicast=yes wireless=IEEE 802.11
linuxium@ROCK-Pi-X:~$ sudo lshw -C display
description: VGA compatible controller
product: Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Integrated Graphics Controller
vendor: Intel Corporation
physical id: 2
bus info: pci@0000:00:02.0
width: 64 bits
capabilities: pm msi vga_controller bus_master cap_list rom
configuration: driver=i915 latency=0
resources: irq:167 memory:90000000-90ffffff memory:80000000-8fffffff ioport:f000(size=64) memory:c0000-dffff
linuxium@ROCK-Pi-X:~$ dmesg | grep "MMC card"
[ 2.348586] mmc0: new HS200 MMC card at address 0001
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 001 Device 002: ID 046d:c31c Logitech, Inc. Keyboard K120
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
linuxium@ROCK-Pi-X:~$ lspci -nn
00:00.0 Host bridge : Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series SoC Transaction Register [8086:2280] (rev 36)
00:02.0 VGA compatible controller : Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Integrated Graphics Controller [8086:22b0] (rev 36)
00:03.0 Multimedia controller : Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Imaging Unit [8086:22b8] (rev 36)
00:0b.0 Signal processing controller : Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Power Management Controller [8086:22dc] (rev 36)
00:14.0 USB controller [0c03]: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series USB xHCI Controller [8086:22b5] (rev 36)
00:1a.0 Encryption controller : Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Trusted Execution Engine [8086:2298] (rev 36)
00:1c.0 PCI bridge : Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCI Express Port #1 [8086:22c8] (rev 36)
00:1f.0 ISA bridge : Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCU [8086:229c] (rev 36)
01:00.0 Ethernet controller : Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 07)
I then set the CPU Scaling Governor to ‘performance’ and ran some Linux benchmarks for which the majority of the results are text-based but the graphical ones included:
And for the same set of Phoronix Test Suite tests the results were:
All of the results can be compared with the Intel Compute Stick model STK1AW32SC which is an actively cooled mini PC with similar spec but with the slightly older x5-Z8330 variant of the CPU and only 2GB RAM as well as smaller storage:
again showing that the Radxa ROCK Pi X performance is as expected and confirming that the processor is not suitable for gaming in Ubuntu.
Rock Pi X Video Playback in Browsers & Kodi
I tested video playback in Edge, Chrome, and Kodi on Windows and in Firefox, Chrome, and Kodi on Ubuntu. When playing videos thermal throttling often affected how they looked and this is discussed further in the ‘Thermals’ section below.
4K playback is beyond this processor. Although 1080p at 30 FPS was watchable in browsers an interesting phenomenon was observed in Ubuntu where after dropping the resolution from 1080p to 720p expecting to get fewer dropped frames it actually got worse as the codec changed from ‘vp9’ to ‘av01’:
In browsers 1080p at 60 FPS didn’t play well:
as 60 FPS videos needing at least 720p in Windows to be watchable and 480p in Ubuntu which then resulted in them playing at 30 FPS.
Kodi plays 30 FPS H.264 videos successfully using hardware decoding:
However, 60 FPS H.264 videos stall and skip frames as do VP9/H.265/HEVC encoded videos which use software to decode:
The following tables summarise the tests and results for each of web browsing:
and in Kodi:
Windows vs Ubuntu
Whilst a detailed comparison between the two operating systems is beyond the scope of this review, it is worth noting some of the key findings I observed. First looking at the performance tools common between the two systems. Overall Ubuntu performs slightly better in the benchmarks than Windows and this can be visually shown by comparing the same Phoronix Test Suite benchmarks in each OS:
For video playback in browsers, Windows is slightly better than Ubuntu with slightly fewer dropped frames.
The Seeed Studio unit was supplied just as an SBC without any form of cooling for the CPU. It was evident early on when running benchmarks that the CPU was reaching high temperatures and being throttled as a result. Switching to the Radxa unit with its heat sink did reduce the CPU temperature but it still wasn’t as effective at dispersing heat compared with a passively cooled mini PC.
In Ubuntu a simple ‘stress’ test shows how quickly the CPU throttles without any form of cooling:
Without the heat sink, the temperature of the CPU quickly climbed to 83°C and the CPU frequency was stepped down and reduced by 500 MHz in under a minute. However with the heat sink during the same period, the temperature only climbed to 67°C and the CPU frequency remained constant.
Whilst the heat sink was effective in reducing the immediate temperature increase caused by the stress test after letting the test run for 20 minutes the CPU temperature gradually climbed to 73°C albeit without any throttling. Once the stress test completed the CPU temperature did drop immediately to 63°C but it took nearly 15 minutes to get back to the starting temperature of 57°C:
With a fluctuating load, however, the effect is that once the CPU heats up it remains hot simply because the heat sink heats up to the point where as quickly as it tries to dissipate its heat the CPU is repeatedly heating it back up. Ideally, a fan is required to create airflow across the heat sink to dissipate its heat.
Another example is when playing a 1080p video in Edge on Windows. When the video was started the CPU temperature was 49°C. After approximately 13 minutes of playback the CPU temperature climbed to 71°C:
After a further 8 minutes one CPU temperature hit 74°C and immediately throttled slightly:
Within a few minutes, all CPUs had started to throttle significantly and playback began to stall:
Eventually, all CPUs were constantly throttled resulting in the video being unwatchable:
further demonstrating that given the room temperature was only 23°C without airflow over the heat sink it was no longer effective.
A final example of the effect of thermal throttling can be seen when running the 3DMark benchmark. Normally I run ‘Sky Diver’ followed immediately by ‘Fire Strike’. When I did this the result from ‘Fire Strike’ was only 114:
However days later when I realized it had been throttled and was substantially lower than expected I reran ‘Fire Strike’ and the result was nearly double at 202.
Network connectivity throughput was measured on Ubuntu using ‘iperf’:
The WiFi results were as expected for this module however the Ethernet upload was rather slow.
Power consumption was measured as follows:
- Powered off (shutdown) – 0.0W (Windows) and 0.0W (Ubuntu)
- BIOS – 3.3W
- GRUB boot menu – 3.5W
- Idle – 2.2W (Windows) and 2.7W (Ubuntu)
- CPU – 5.2W (Windows ‘cinebench’) and 5.4W (Ubuntu ‘stress’)
- 1080p 30 FPS videos* – 6.7W (Windows Edge) and 7.2 (Ubuntu Chrome)
*The power figures fluctuate so the value is the average of the median high and median low power readings.
The BIOS is quite unrestricted and detailed instructions on upgrading are available from Radxa’s website.
The key attraction of this SBC is likely to be the ability to get x86 architecture for a relatively low price. By including a 40-pin expansion header the device is suitable for multiple projects where GPIO connectors are required.
Whilst the ROCK Pi X performance can be similar to other devices with the same CPU the effect of insufficient cooling can impact this considerably.
The driver issues will be of concern for those wanting a working ‘OOTB’ solution. They may all be fixable but will require some effort and research.
|x86 architecture||Driver issues|
|Low cost||Additional cooling required|
|40-pin GPIO header||Dated (low performance) CPU|
I’d like to thank both Seeed Studio and Radxa for providing ROCK Pi X for review. The model sold on Seeed Studio with 4GB RAM, 32GB flash, and no heat sink goes for $75 plus shipping. The board sent by Radxa currently retails at around $107 (excluding power adapter and shipping) on Allnetchina for the tested 128GB and heat sink configuration. Alternatively, you’ll also find it on Aliexpress for a total of around $155 shipped.
Ian is interested in mini PCs and helps with reviews of mini PCs running Windows, Ubuntu and other Linux operating systems. You can follow him on Facebook or Twitter.
42 Replies to “Rock Pi X Review – An Atom x5 SBC running Windows 10 or Ubuntu 20.04”
Nice review Ian. The board looks pretty similar to the original UP board, which I have and really like. It remains cool, is stable, not very powerful but quite versatile, and remains one of the always-on devices I have at hand for whenever I need a shell on another machine. And the fact that the price of all boards using this chip doesn’t fluctuate much after this long is probably an indication that it remains a good product.
Regarding the throttling, it’s strange that it starts to throttle at this low a temperature, as the chip is supposed to withstand 90°C (and the SoC targets a 2W SDP). Probably that some DVFS (or the windows equivalent of it) are a bit excessive. I never managed to get mine to throttle even while building kernels at -j4 with the 4 cores at 1.68 GHz, despite its slightly thinner heat sink. Also, it’s worth keeping in mind that the highest the temperature, the faster it goes down as it radiates more to the ambient air.
There is an entry in the BIOS enabling DPTF and setting the Skin Hotspot Proxy Thermistor Participant to 65°C and this is also set as a trip point in /sys/class/thermal so may explain some of the thermal throttling.
By the way, the x5-8550 has increased frequencies, a second PCIe lane, two memory channels instead of one, supports 4 times more memory, and is only $4 more. It would definitely make a great solution for plenty of SBCs (e.g. SATA+GbE+USB3+display+lots of RAM).
Because that would make sense. And it would make even more sense to include the x7-8750, which is roughly 40-50% more powerful than the x3-z8350 for $15 more.
I would go even further, a board with that CPU, no eMMC, uhs2 support for microsd paired with 8GB of RAM could go for under $100 for sure. These Atoms aren’t “somewhat dated” they are just a refresh version of the hugely outdated ultra low cost CPU’s from Intel, which are dated from 2013. In fact, in 2013 they were already slow, and you could notice it using Windows 8.1 with them.
If they keep using those for sbc they have 2 options: lower the price to the $50-60 range or use the fastest cherry trail CPU paired with 8GB for $80-100 range. We are in 2021 and they are still being cheeky to release boards with this CPU for these kind of prices.
I know it’s a little different scenario, but I recently bought a Mini PC not much bigger than a Raspberry for roughly $140 shipping included, and it comes complete with case, heatsink+fan, Intel J4125, 8GB RAM and 128GB M2. If you want to get the complete set for the RockPi X you have to add some bucks more to those $107, so in the end you get the same price for a way less powerful mini computer.
Where’s the deal here, can anyone explain me with other words than “it has GPIO” or “you can make interesting things with it that otherwise you can’t with a commercial product”?. C’mon, this sbc market is becoming crazy, releasing more and more products with prices like they were vintage items, and this is the proof.
Very nice in depth review. However, I’d not buy one since I already own a much powerful Odroid-H2+ and being using devices with same Intel Atom x5-Z8350CPU’s since 2016. Hackerboard2 Linux edition at comparable price would be a better deal for a x86 SBC board. Just waiting for Radxa RockPi5.
In the first table there’s ‘1.84 GHz’ mentioned that should most probably read ‘1.92’ instead?
And a question: Is the NIC an RTL8111F or a later revision?
Table source is ‘https://wiki.radxa.com/RockpiX/getting_started#get_start_specs’ so yes this is wrong and should be ‘1.92’.
The Ethernet NIC is an RTL8168F based on lshw/lspci ‘[10ec:8168] (rev 07)’ which uses the ‘rtl8168e-3_0.0.4’ firmware and 8169 driver in Ubuntu.
> RTL8168F based on lshw/lspci
Thank you though I was asking for the readings on the chip 🙂
RealTek has/had a pretty bad reputation in the past wrt their PCIe NICs but I believe it got better with more recent 8168/8111 revisions. Due to the bad iperf performance in one direction I ask for this speficically.
Would be interesting to see whether a CPU core is maxing out during iperf and/or whether ethtool shows a huge amount of retransmits afterwards.
I was used to seeing terrible performance with realtek chips in the past (including pcie) and that was also the reason I always stayed away from Gigabyte mobos (which were nicely designed but always came with that crappy chip as if it was important to save the last dollar). But recently while telling a few coworkers “nah don’t use that crap”, I figured they could get decent performance with no signs of drops, so I think that some of these atrocious chips have made some important progress and/or that drivers learned to better talk to them.
> I think that some of these atrocious chips have made some important progress
Same here. But I thought it started with RTL8111G/H that’s why I’m so curios which revision the chip on the RockPi is (based on the picture I would believe it’s an RTL8111F but it’s too blurry to be sure).
I can confirm it is an RTL8111F on both Radxa’s V1.3 board and Seeed Studio’s V1.4 board.
I have now run ‘ethtool -S’ and ‘netstat -s’ both before and after running new ‘iperf’ tests as well as logging CPU utilisation during the ‘iperf’ runs. There was nothing of interested in a ‘diff’ of the ‘ethtool’ logs and the ‘diff’ of ‘netstat’ logs confirmed there were ‘0 segments retransmitted’. However the logs from the CPU utilisation are far more interesting as during the download measured this time at 920 Mbits/sec CPU4 was running at 100% whereas during the upload now measured at 687 Mbits/sec CPU4 averaged 59% utilisation. This was also repeatable (920/687/59%, 922/686/57% & 921/688/58%) so on average CPU4 always ran at 58% utilisation during upload resulting in approximately 25% slower speed.
Thank you for the update! Well, maxing out one CPU core during download while missing 940 mbit/sec is really bad. Since CPU utilization and cpufreq scaling are two different things would be interesting to monitor /sys/devices/system/cpu/cpufreq/policy3/cpuinfo_cur_freq while running these tests. Also to pin iperf to a specific core using taskset.
Too much to ask for so I guess I’m going to search for my UP board lying around somewhere (but this has an 8111G).
Well, pointless to test with an UP board since confirmed to reach full GbE speeds. The Atomic Pi that also relies on 8111G (‘rev 0c’ in lspci output) is able to reach/exceed 940 Mbit/sek in both directions too according to frank-mankel.org.
Running ‘iperf’ and monitoring just CPU4:
Download 923 Mbits/sec, avg CPU4 util 100%, avg CPU4 freq 1860MHz, avg CPU4 temp 53°C
Upload 677 Mbits/sec, avg CPU4 util 51%, avg CPU4 freq 1884MHz, avg CPU4 temp 53°C
Running ‘iperf’ pinned to just CPU4 (taskset –cpu-list 3):
Download 917 Mbits/sec, avg CPU4 util 100%, avg CPU4 freq 1863MHz, avg CPU4 temp 53°C
Upload 682 Mbits/sec, avg CPU4 util 61%, avg CPU4 freq 1877MHz, avg CPU4 temp 53°C
So basically during upload CPU4 runs at a slightly higher frequency but with a much lower utilisation resulting in a slower speeds.
Well, when looking at these numbers a few things come to my mind: what if iperf is pinned to cpu1 instead (when downloading also IRQ processing can become a bottleneck)? What about RPS settings?
Time for some active benchmarking but since it seems it’s related mostly to chip revision the simpler attempt is trying to avoid RTL8111 prior to 8111G.
Pinning ipref to a CPU (e.g. CPU1) either by command or by all iperf processes doesn’t change anything as CPU4 always runs at around 50% softirq and upload speed consistent at 684 Mbits/sec.
RPS was at default (0) and setting to ‘f’ seemed to added 10 Mbits/sec to the upload speed (694 Mbits/se) during the limited testing performed (of just 3 runs).
> during upload CPU4 runs at a slightly higher frequency
I would call both numbers identical, at least they’re at the upper level the CPU cores will be clocked with single-threaded loads.
I asked for this based on some experiences with an ARM SoC years ago where cpufreq scaling settings in an Allwinner BSP kernel resulted in pretty bad iperf numbers while in real-world scenarios due to other processes involved cpufreq got ramped up from 408 to 1152 MHz so only benchmark numbers suffered but not real-world performance.
Excellent point, I forgot that my UP board had one indeed:
01:00.0 Ethernet controller : Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 0c)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:0123]
I’m getting only 26% of one CPU core at 950 Mbps bidirectional traffic forwarded through a local haproxy process, so it’s definitely *not* a problem there.
> RTL8111/8168/8411 … [10ec:8168] (rev 0c)
Yes, this is an 8111G in the UP board. Can you please provide output of ethtool -i for the interface so we’re also able to compare driver and firmware versions?
firmware-version: rtl8168g-2_0.0.1 02/06/13
> rtl8168g-2_0.0.1 02/06/13
Thank you. That’s the same firmware that’s used on ODROID H2 with Ubuntu 18.04 while Ian reports the 8111F on the RockPi X uses this one: rtl8168e-3_0.0.4 03/27/12
Since driver versions are missing lets stop here. I would say it’s save to assume that at least revision G of the RTL8111 should be used these days…
> I’m getting only 26% of one CPU core at 950 Mbps bidirectional traffic forwarded through a local haproxy process, so it’s definitely *not* a problem there.
I was wrong, it’s what “top” reports on aggregate but when looking in details it’s more like 59% of softirq on a single core and sometimes it even climbs between 80-90% on this core. The one running haproxy is 94% used anyway. If I put the two on the same core, they reach 100% and the bit rate drops to 840 Mbps (or 885 with TCP splicing). iperf -d gives me 755rx+880tx on different cores and 760rx+750tx on the same core. Thus the chip remains somewhat expensive to use. When you see “ethtool -c” showing 0 in rx-usecs and 1 in rx-frames you know you won’t go very far. Hmmm interesting discovery, TCP csums were disabled (hence disabled SG, GRO, GSO). Now I’m seeing 920 Mbps for haproxy at 100% on the same core, only 40% softirq on different cores. iperf on same core gives 760+899, and 750+876 on different cores (yes I know it’s lower but it’s never stable anyway).
Ian, you may be interested in checking ethtool -k and possibly issuing “ethtool -K eth0 tx-checksum-ipv4 on and “ethtool -K eth0 sg on” then rechecking.
Running ‘ethtool -c’ does show ‘rx-usecs: 0’ and ‘rx-frames: 1’ so can you elaborate the implications of this please?
Running ‘ethtool -k’ shows ‘tx-checksum-ipv4: on’ and ‘scatter-gather: off’ with an upload speed of around ‘674 Mbits/sec’. Turning ‘sg’ on actually results in a slower upload speed of around ‘512 Mbits/sec’.
I also then tried setting RPS to ‘f’ with ‘sg’ on and this improved the upload speed slightly although it became somewhat unstable but the best seen was ‘524 Mbits/sec’.
Overall the best upload speeds were when only RPS was set to ‘f’ giving upload speeds of around ‘688 Mbits/sec’
rx-usecs ad rx-frames respectively indicate how long the NIC will wait before delivering an interrupt, or how many pending frames. Here it means there’s one interrupt per frame so rx traffic generates lots of IRQs (which are actually moderated by NAPI), which induce higher CPU usages at moderate loads. At very high loads it will not change anything once your ksoftirqd already runs in polling at 100% CPU.
It’s amusing to see that sg:on slowed everything down. The purpose is to allow passing vectors to the NIC so that it reads data in small chunks instead of doing a preliminary copy to assemble everything. It could be caused by PCIe saturation on the transaction rate, that without SG wouldn’t happen because the fragments are assembled much faster by the CPU into the cache, requiring a single transaction to read them from the NIC.
If you got best performance with RPS set to “f”, you can check in /proc/interrupts if your IRQs are delivered to all 4 cores or a single one. My UP board is configured to deliver to only one core:
$ grep $(ip li|grep BROAD|cut -f2 -d:) /proc/interrupts
145: 0 588 0 84186722 PCI-MSI 524288-edge enp1s0
$ cat /proc/irq/145/smp_affinity
At moderate loads on such small CPUs you can easily reach saturation in the driver on this single CPU even with RPS enabled. It’s often pretty efficient to exclude the CPU receiving interrupts from the RPS mask. In my case, that would mean excluding CPU3 from rps_cpus. That would give 7. In this case the core the driver runs on does nothing but dealing with the driver and the stack runs on the other cores.
Thanks for the explanation.
The ROCK Pi X is similar to the UP board in that ‘smp_affinity’ defaults to ‘8’ so ‘smp_affinity_list’ is ‘3’ meaning CPU4 processes all the interrupts. I can move this around to a different single CPU but when ‘smp_affinity’ is set to ‘f’ to bring in play all CPUs, still only a single CPU is used to process the interrupts which also seems to be the most recently used CPU. Unfortunately excluding the CPU that is processing the interrupts in the RPS mask didn’t add any further improvement to the performance seen from using all CPUs for RPS.
Apparently someone sold his boss plenty of realtek cards and doesn’t like our experience reports about them 🙂
Great review quite informative.
If I had some specific purpose in mind I would certainly consider one of these. The price is about right to where it would be worth working through the issues that are sure to crop up.
No information was provided as to the placement and orientation of the heat sink.
If you left it standing lengthwise like the heat sink is blatantly obviously designed for it wouldn’t have taken 15 minutes for it to drop from 63°C to 58°C in a 23°C environment.
If you left it flat on the table, heat sink up, these results might be considered surprisingly poor despite the handicap it’s facing.
If you left it flat on the table, heat sink down, so there was no airflow over it, then these results are to be expected since the function of the heatsink was outright sabotaged.
Based on own testings with similarly (bad) heatsinks for NanoPi NEO4 and M4 I fear I have to disagree. Those heatsinks with a huge thermal mass act as an own heat source and feed back thermal energy into the board after load peaks. Orientation or position are pretty much irrelevant. Though with heatsinks that are made for the job (passive cooling –> low own thermal mass, huge heatsink fins with adequate spacing) it’s an entirely different story.
The Radxa unit with the heat sink was tested lying flat with the heat sink up as in the picture above in the ‘Accessories’ section. The Seeed Studio unit was also tested lying flat with the CPU face up so basically both were tested in the same orientation. Testing either unit standing lengthwise was not really possible as the weight/pull and torque created by the connected cables inevitably toppled the board over.
Wouldn’t an AtomicPi board be a contemporary of these? The limited eMMC an DRAM of that board might place it below these two, but the included audio and heatsink (as well as the lower price) might make up for that.
Atom x5 can be an interesting (low power) platform for software testing for Intel hd gpus. On usb 3.0 can be sufficient for customer hardware device functionality verification. (Later ‘Apollo Lake’ then started on lpddr4.) Therefore decision between thermal throttling, because of tiny form factor preferences or additive air flow is caused mostly by customers?
Atom’s will be discussed pretty much this year for sbc like platforms?
I experimented a little bit with OpenCL on my x5-z8350 a year or two ago, but I quickly gave up, not managing to get similar results as on another machine, I figured it was definitely not something for me 🙂
Tested image processing on opencl 1.2 and tensorflow on predecessor platform (what compares to Arm’s Mali Midgard 3rd/4th gen gpu, considering cl support) for software compatibility reason and basic insights into hands-on artificial intelligence. Experienced Vulkan 1.0 supported (partly) on 2014/2015 Atom platform. Thanks to Apple, Arm and Intel programmers and sbc developers.
for into Arm’s gpu opencl (shown on a Hardkernel Odroid, Samsung Exynos, Xu4)
Yep and I remember successfully trying my faulty program on my MC1 after reading that very useful article!
Isn’t Cherry Trail limited to HDMI 1.4(b) in output terms? 4K@30Hz max suggests so – as that is the max resolution that HDM 1.4 supports?
I’ve not seen any other Cherry Trail platforms with HDMI 2.0 output – this feels like a mistake?
4K@30Hz or 3840×2160 at 30 Hz is the maximum for the HDMI Specification 1.4b which also includes support for 1920×1080 at 120 Hz however the Intel Atom Processor Z8000 Series Datasheet Vol. 1 for the Z8350 which is Package Type ‘T3’ states the display is HDMI 1.4b and has a maximum resolution of 1920×1080@60fps. Testing video playback on the ROCK Pi X also confirms this so I agree that the ‘HDMI 2.0′ in Radxa’s specification must be a mistake and it is actually HDMI 1.4b.
Adding tax and shipping, I can get Pentium laptop at this price..,
Or used J3455 Nuc with 4GB/500GB in my case.
For KODI it’s better to use LibreELEC, also, one more thing – this board support h264 10bit (aka anime)
This review unfortunately has explained a lot to what’s going on with my boards, I installed the heat sync with the thermal pads provided and the CPU sits at 100% throttling, cant even run any videos as it was meant as a work PC so I wanted it to run some 3D printing programs and videos or CAD with nothing working, now I wish I didn’t get mine lol