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

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.

   Reply

   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.

      Reply

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

   Reply

   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.

      Reply

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.

   Reply

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?

   Reply

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

      Reply

      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.

         Reply

         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.

            Reply

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

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

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

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

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

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

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

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

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

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

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

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

                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.

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

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

   Reply

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.

   Reply

   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.

      Reply

   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.

      Reply

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.

   Reply

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?

   Reply

   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 🙂

      Reply

      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.

         Reply

         1. for into Arm’s gpu opencl (shown on a Hardkernel Odroid, Samsung Exynos, Xu4)
            https://www.cnx-software.com/2018/05/13/how-to-get-started-with-opencl-on-odroid-xu4-board-with-arm-mali-t628mp6-gpu/

            Reply

            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?

   Reply

   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.

      Reply

10. Adding tax and shipping, I can get Pentium laptop at this price..,

    Reply

    1. Or used J3455 Nuc with 4GB/500GB in my case.

       Reply

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

    Reply

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

    Reply

Leave a Reply

Connect with:

Your email address will not be published. Required fields are marked *

Comment *

Name *

Email *

Website