Rock Pi X Review – An Atom x5 SBC running Windows 10 or Ubuntu 20.04

Rock Pi X Review

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…

Left: ROCK Pi X Model B; right: original Red Raspberry Pi Model B for the Chinese market

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:

Box contents

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:

Review Methodology

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:

The Radxa’s website tip to toggle DTS in the BIOS did not fix the Nuvoton driver. However, during testing, it was found that the BIOS was an earlier version so it was upgraded to Radxa’s latest published version of ‘V12_X64_20200924’. Whilst this didn’t fix the missing drivers it may have changed the behavior of the Nuvoton driver as it now appears to be unstable as sometimes on boot it works in Windows:

and sometimes after a reboot, it fails in Windows:

However, the same Nuvoton device also had a problem in Ubuntu on this unit:

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 ‘‘.

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:


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.

Ubuntu Performance

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:

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

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.

Final Observations

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 architectureDriver issues
Low costAdditional cooling required
40-pin GPIO headerDated (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.

Share this:

Support CNX Software! Donate via PayPal or cryptocurrencies, become a Patron on Patreon, or buy review samples

42 Replies to “Rock Pi X Review – An Atom x5 SBC running Windows 10 or Ubuntu 20.04”

  1. 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.

    1. 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.

  2. 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).

    1. 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.

  3. 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.

  4. 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?

    1. Table source is ‘’ 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.

      1. > 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.

        1. 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.

          1. > 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).

          2. 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.

          3. 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).

          4. 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.

          5. 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.

          6. 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).

          7. > 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.

          8. Excellent point, I forgot that my UP board had one indeed:

            01:00.0 Ethernet controller [0200]: 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.

          9. > 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?

          10. Sure:
            driver: r8169
            firmware-version: rtl8168g-2_0.0.1 02/06/13
            bus-info: 0000:01:00.0
            supports-statistics: yes
            supports-test: no
            supports-eeprom-access: no
            supports-register-dump: yes
            supports-priv-flags: no

          11. > 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…

          12. > 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.

          13. 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’

          14. 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.

          15. 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.

          16. Apparently someone sold his boss plenty of realtek cards and doesn’t like our experience reports about them 🙂

  5. 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.

  6. 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.

    1. 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.

    2. 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.

  7. 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.

  8. 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?

    1. 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 🙂

      1. 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.

          1. Yep and I remember successfully trying my faulty program on my MC1 after reading that very useful article!

  9. 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?

    1. 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.

  10. For KODI it’s better to use LibreELEC, also, one more thing – this board support h264 10bit (aka anime)

  11. 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

Leave a Reply

Your email address will not be published.