ODroid H3/H3+: x86 SBCs with Qubes and Ubuntu

Best Read Here: https://www.sevarg.net/2023/10/21/odroid-h3-x86-sbc

This week, I’m reviewing something rather different for me - a pair of small form factor x86 SBCs with recent generation performance on a (generous…) ARM SBC power budget! I present the ODroid H3 and H3+!

Yeah. They look absolutely identical. They’re both quad core x86 systems with proper RAM support (up to 64GB), NVMe support, proper networking (a pair of 2.5G ports, with an option for more if you want them), and a convenient small form factor. I’m looking at them from the perspective of desktop use - in the “mid-desktop” sort of slot I’ve been using Raspberry Pis, ODroid N2s, and the like.

Why x86?

If you’re a bit weirded out over my return to x86, well… so am I, and I hope it’s temporary. But I’ve discovered the virus that is Qubes, and it’s spread over the past few years from “A play computer” to “All my daily driver computers.” The internet is a hostile, hostile place anymore, and being able to more meaningfully separate out different categories of tasks (blog, email, core web, random web browsing, assorted web dev toolchains that involve piping curl to bash, sysadmin, etc) without sharing a kernel is worth a decent amount to me. The state of computer security is quite poor these days, as we see with the steady stream of “You probably ought to apply this update soon, it fixes something being exploited in the wild…” announcements. I don’t claim Qubes solves everything, but it does provide some meaningful additional separation between VMs, and I find the whole “disposable VM” thing an incredibly handy feature - it makes it easy to perform a wide range of tasks (say, the “curl ... | bash” constructs) in entirely ephemeral VMs. As Qubes doesn’t yet run on ARM and I don’t have the free time to make that port right now, an inexpensive enough x86 system that can slot into the “low power, always-on machine” places I currently use ARM has some value. Also, the state of ARM GPU drivers on the modern chips is just a hot mess…

The short answer is “I still don’t like x86, but the ability to run Qubes is worth a decent amount to me right now.” On the other hand, I don’t really have the overnight power budget in my office for an always-on full desktop, so the small, low power form factor is still worth pursuing.

The ODroid H3/H3+

The ODroid H3/H3+ are a pair of little x86 SBCs - Small Board Computers. In practical terms, these are an Atom SoC Breakout Board - they take one of Intel’s Atom SoCs (system on chip), and bolt on enough extra stuff to make it run and allow you to interface with it. Practically, this means a big heatsink with some ports around it.

The difference between the two systems (H3 and H3+) is the choice of processor. The H3 comes with an Intel Celeron N5105 - 4C/4T, Jasper Lake, 2.9Ghz peak turbo frequency, and 24 graphics execution units peaking at 800MHz. The H3+ has an Intel Pentium Silver N6005 - roughly the same thing, but a 3.3GHz peak turbo frequency, and 32 graphics execution units peaking at 900MHz. They otherwise have the same processor cores, the same amount of cache, etc. While you’ll notice the Intel Ark pages report a max of 16GB RAM, the SoCs support both DDR and LPDDR4, and I’ve been testing them with 32GB, no problems. They claim to support 64GB, I just didn’t feel a need to test that high as I don’t need that much. The systems do support dual channel mode for memory, and that’s something I’m going to examine as well - just how much performance do you lose with a single stick of RAM?

The back has most of the ports you’re likely to care about, and it’s a pretty solid selection! On the left is the power connector - a beefy barrel jack that works out to “NUC-spec.” It takes 14-20V at some reasonable amperage that depends on how many drives you’ve hung off the system. I’m glad we’ve found something resembling sanity with “small form factor power supplies” these days, because just about everything “small and x86” takes the same general voltage range, and will happily run on each other’s power supplies.

A pair of USB 2.0 ports (black) and a pair of USB 3.0 ports (blue) hang out below the pair of RTL8125B network ports - they support up to 2.5Gbit. If you want more network ports, you can get an expansion card with another 4 that lives underneath and gives you a total of 6 ports for routing duty. Continuing over, these boards have both DisplayPort 1.2 and HDMI 2.0 connectors, supporting up to 4k@60Hz, and while I’ve not tested it, you should be able to use both for dual monitor support. Finally, on the right, there’s 3.5mm audio out, 3.5mm audio in, and a S/PDIF optical audio output. It’s a pretty useful set of ports (and would make for a good HTPC) but let’s keep going around.

Around the side, a pair of SATA3 6G ports support various drives for bulk storage. Those two white ports to the left connect to an optional SATA power cable so you can power drives directly off the board (though it’s recommended you use a larger power supply for the board if you’re doing this). Above those power ports is the eMMC connector, if you want to use one of those as your boot storage. Depending on what you’re doing, that may be more than enough for your use cases, as the newer ones are reasonably quick. Just not NVMe quick.

The last interesting corner has a power and reset switch (rare for ARM SBCs, common on x86), a slightly less-than-useful GPIO header, and a standard enough four pin fan hookup - which you will need if you want to run this thing flat out.

Underneath, there’s a pair of RAM slots for DDR4, and a M.2 slot for a NVMe SSD. The H3s do not support M.2 SATA SSDs - it’s simply not wired through for it. NVMe only. Not that there’s any good reason to be using a SATA M.2 SSD in 2023 in the first place. Seriously. NVMe is Just better. There’s not even a big cost difference anymore.

Initial Setup and BIOS Updates

Initial setup is similar to any other system. Add RAM. Update BIOS. Add storage. The only real gotchas about this system are that you’ll need to pull the CMOS battery for the update process - per the official instructions, which you should read.

Also, this system takes a long time to POST after any configuration changes. If it takes a minute to bring the video up after some changes, or on initial power on, this is normal. Don’t worry. It’s training the RAM and should be a lot faster after it’s saved the settings.

Download the latest BIOS, extract the zip into the root of an otherwise blank FAT32 USB drive, and boot the system. If you don’t have any other storage in place, it should just dump you into an EFI shell, of which you’re either entirely ignorant of, or quite familiar with. I’m not sure too many people “sort of know about it.” I’ve spent a lot of my life in such a place. In any case, you’ll want to run the proper flash script for your board (there’s a difference if you have the add-on network port board, which I don’t).

Run the update script, and you should have the board updated after a few minutes. Pull power, let it sit for a few seconds, re-connect the backup battery, and enter the BIOS to see what you’ve got laying around. It should be updated to whatever you flashed!

Enter the Firmware, Enable Unlimited Mode

If you’ve spent any time with other “SoC Breakout Board” classes of hardware, this should be a pretty standard feeling BIOS. If not, well… you’ve got Options with a capital O. Console redirection, lots of performance options (though no overclocking - it’s an Atom, not a desktop chip). But there’s a very important option you need to change if you want full performance off this system, and that’s the Power Limit 4 value in the CPU Power Management section. You want to put a fan on the system, and then set this to 0. That opens up unlimited performance, which I’m at least using while poking and prodding the system. If you want to restrict power output, you can also set this lower - it’s a handy tool, but for desktop use, with a fan, open ‘er up and let ‘er rip! You might also want to configure your fan settings - there are a few profiles, but any of them should be generally fine. If you’re planning to run the chip hard, though, you do need a fan.

Toss the performance governor on Linux, and it should purr along nicely at either 3.3GHz (H3+), or 2.9GHz (H3). On the other hand, if you want to improve efficiency, you can clamp this down at the cost of performance. All my benchmarking here is done with unlimited PL4 and a fan.

Ubuntu Installation

Stuff 22.04 on a USB stick, boot it, and when it looks like it’s locked up after the throbber stops spinning, go get a cup of coffee and wait a bit. It should eventually bring up the installer screen and let you install. Unlike a lot of the ARM SBCs, this really is just a bog standard x86 platform down there. Once you’re installed, do a full OS update, and you might consider sudo apt install linux-generic-hwe-22.04 to make sure you’re on a more recent kernel than stock (though I think the current 22.04 installers have this enabled already). I don’t know that it makes a difference, but this is more recent hardware than I normally mess with.

It’s really just a bog standard Ubuntu 22.04 install, without anything insane to make it happen. This is oddly nice in my world. You can just install stuff normally. Even crazy things like Spotify or Steam. I’m not sure quite what to make of it.

Qubes Installation

Um… look, I know my posts about SBCs typically are half “The fine art of installing a decent OS on this system.” Flashing images, hacking them, installing them, custom kernel builds, and the like. I have my complaints about x86, but installing OSes isn’t one of them, and QubesOS 4.1 just slides right on. The ODroid H3 and H3+ are entirely Qubes compatible, out of the box, with no heroics. You don’t even have to mess with hyperthreading settings, because it doesn’t have hyperthreading support!

Performance Testing

All of my testing here is done in unlimited mode, with a fan turning. I’ve set the performance governor under Linux (sudo cpufreq-set -g performance). You can always reduce power and performance (typically improving efficiency in the process), but I’m interested in what it is, fully uncorked. I’ve done the tests as well with one and two sticks of RAM - 1R and 2R. This is a dual channel capable chip and board, so a reasonable question is, “How much does it matter?”

And then I’m also doing the testing with the H3 and the H3+. I don’t expect a huge difference between the two in CPU performance, though there should be a bit of a gap in GPU performance. I’m also throwing in a few other systems worth of performance data so you can get a feel for how this compares, performance-wise, against some other halfway modern hardware.

The Rock5B is a recent ARM SBC that very much rocks right along - just with horrible GPU support at the moment. The Lenovo X250 is a little Lenovo Ultrabook from some while back with an i5-5300U. I include it simply because it’s my current “daily driver” laptop, so reflects what, to me, is “entirely adequate performance.” And then for desktop systems, I’ve got a Ryzen 5700X based system as a representation of a fairly modern desktop - it’s not absolutely bleeding edge, but it’s a respectable desktop system from the past few years. If you see the bar for that one missing in some chart, translate it as “It crushed everything else by enough to screw up the chart scaling.”

I’m not doing disk benchmarking because it’s a bog standard NVMe interface, and therefore is “more than fast enough to not matter a bit in regular use.” Your choice of drive determines performance, and anything is so much faster than the SD card and eMMC interfaces that it’s simply no longer a factor in practical daily performance.

I’ll start out with Geekbench 5. The 5700X scored 9314 multicore, so I’ve left it out. In a pattern that you’ll see consistently, the single threaded performance on the H3s is about half that of the 5700X, and otherwise it runs in about the same range as the Rock5 and my laptop - so, more than useful performance. You can see the clock speed difference between the H3 and the H3+, and in a pattern you’ll see throughout the charts, dual channel RAM does make a very real difference. While it didn’t matter for single threaded performance, once the system was loaded up multicore, the better bandwidth with dual channel RAM is quite noticeable.

Moving on to some memory benchmarks (as modern CPU performance is mostly memory limited for general purpose desktop workloads - if you wonder why Apple’s M series chips are so fast, just look at their memory bandwidth), mbw copies hunks of memory around with a range of techniques. Here, you really see the single channel/dual channel performance split. And, once again, the H3s run even with a range of other compatible systems - and a full desktop chip shows off some of the optimizations that you can make when you have a far higher power budget. I ran tinymembench as well, but the results were largely the same, so I’ve not included that chart.

Since modern “desktop” use is largely defined as “run a browser, or run an embedded browser pretending to be a desktop application,” browser benchmarks are always interesting. The X250, to me, represents more than adequate browser performance (I actually tend to run it Jitless), and the H3/H3+ purr along just fine too. It’s not world class desktop performance, but it’s certainly a lot faster than the little ARM boxes I’ve been using in the past.

One of my other “Well, this is interesting!” benchmarks for system throughput is parallel kernel builds - and this may be slightly related to my habit of building custom kernels for basically everything I run (but, here, with a standard x86 system, I don’t have to). It sweeps from pure single threaded performance to total system throughput, and I stop at “cores plus two” - there just aren’t any gains past that, and usually it gets slower by that point anyway. Once again, if you need the performance of a full desktop, the H3s aren’t there, but they’re perfectly respectable little systems, more or less matching my laptop, and it shows decent enough performance scaling with cores (it’s a 4 core system). Here, RAM speed doesn’t make a huge difference, but clock speed does.

Finally, while I’m not comparing it to other systems (the desktop has a discrete GPU that pulls far more power than the H3, and I don’t do anything graphical on my laptop), you can see the difference between the H3+ and the H3 with regards to the additional GPU elements in the H3+. Again, dual channel RAM matters here. But if you’re going to be gaming or anything else moderately graphically intensive, the performance of the H3+ is a noticeable boost. For general purpose desktop use, I don’t think it matters, and if you’re in something like a framebuffer only environment, it doesn’t mater in the slightest.


Being a little x86 box, it’s actually possible to play some games on this system without the sort of heroics I went through to get acceptable performance on the other little ARM SBVCs I’ve worked with in the past. You just… install stuff.

Minecraft can be installed with the standard x86 Linux installer, and the H3+ manages 40-60fps on my server world, with a render distance of 16 blocks, swinging a 4k monitor in the deal. I know this isn’t a big deal for most people, because Minecraft pretty much runs on everything, but I’ve spent a decent amount of time in the past figuring out how to get it running on ARM.

Steam installs on Ubuntu in the usual, easy way, and proceeds to abuse my increasingly overpriced and underperforming Starlink connection to no end. I don’t have any flagship modern games to test with (nor would I expect them to be playable), but Serious Sam Fusion plays acceptably at lower detail settings.

And, importantly, KSP is playable. You have to turn the detail settings pretty far down, but it’ll play it well enough to have fun!

On the H3, graphical performance is lower, as is to be expected. KSP is unable to hold realtime performance during launches most of the time, and Minecraft manages 35-40fps on the same settings that were getting up to 60fps on the H3+. The main conclusion here is that if you want to play games, the H3+ is a noticeable improvement over the H3. If anything, the graphics benchmark understates the real world graphical performance difference in games.

Power Consumption

Finally, about that whole “Low power x86 machine” thing… what are the actual power draws? I’ve stuck my Kill-a-Watt in the loop to measure.

I’m using the 15V/4A power supply, and these numbers are “at the wall” - and there are some serious problems here.

Idle at the Ubuntu 22.04 desktop, power consumption is roughly 13W. That’s kind of a problem when I was hoping for a lot lower - but it gets worse. The power factor from that power supply is awful. It’s 0.37 or so, meaning that this system is actually pulling 35VA. Do you care? Well, that depends an awful lot on how you’re billed for power, but I’ll suggest you do, because people are mostly billed for VA, not W. There’s a difference.

Crank up the KSP, lob a heavy into orbit (without blowing the launch pad into the back of the rocket - the first Starship launch had what I find a hysterically-termed “Engine-rich exhaust”), and… well, the power factor improves to 0.40! Power consumption is 27W, but 64VA at the wall. This is not impressively low by any means.

Qubes idles around 10.5W, which is more useful to me (but still rather high), with a PF of 0.36 for an idle load of 30VA. This is just gross…

Suspended, the system is pulling 1W, with a PF of 0.20, for 5VA from the wall. To borrow my daughter’s phrase, “Seriously?

Basically, the stock power adapter sucks, and you’d be well served finding something better for your H3. Fortunately, any of the random NUC power adapters work just fine - but the system is still a good bit more power hungry than I’d been hoping for. I’ll see if it survives the winter.

Final Thoughts

First and foremost, use two sticks of RAM in the H3s. It really does make a difference in performance, especially graphical. There’s just no reason to run a single stick of RAM in these unless it’s for absolute bottom end use.

Otherwise, if you want a small, light, modern-ish x86 SBC, this delivers exactly what it claims to. It’s a reasonably low power (though not exceptionally low, and the stock PSU sucks) x86 box that delivers reasonable daily driver performance for “light to moderate use cases.” And it happens to take Qubes exceptionally well, which is worth a lot to a certain set of people!

This is a companion discussion topic for the original entry at https://www.sevarg.net/2023/10/21/odroid-h3-x86-sbc

I can’t stand how slow Celeron and Pentium chips are. The new N100’s are finally fast enough to be usable for me, but too expensive for my purposes

I continue to use x86 because I know that in 10 years’ time they’ll continue to install, work with, and most importantly; be supported with a mainstream Linux distro (read: easy to maintain for decades; my oldest machine right now is from 2012, a little over 10 years old).

Specifically, I’ve been buying Dell Micro Form Factor Optiplex boxes (basically the same size mobo) for about $100 from Amazon. They’re cheap enough that I buy 5 at a time! Thankfully, Dell has raised their ridiculously low “max RAM” BIOS restrictions to 32GB. These come with an external 19.5 VDC @ 3.34A (65W) PSU. Other features include “wake-on-clock” and complete soft-power button controls in the BIOS.

For $100 you get i3 or i5, a tiny 128 GB SSD, and 8 GB RAM, but old 6th-7th generation CPUs. These CPUs give decent bandwidth to/from disks; SATA access saturates CPUs very quickly.

For me, a tiny headless box that wakes up at 3 AM to rsync my backups offsite is perfect. However, idle power isn’t as low as it could be, so it’s not as useful for a 24/7 appliance. I’ve not attempted to optimize idle wattage, however.

What are you doing with them? I’ve realized that most of my personal compute doesn’t need anything in the way of actual performance.

grumbles in obsolete kernels Yeah. That’s a problem with just about all the ARM boards. If they’re not a Raspberry Pi and don’t get mainline kernel support, you’re stuck on whatever the BSP (board support package, initial distro, etc) ships with.

Got one you wouldn’t mind benchmarking? I’d be interested to see the results!

Another reason to use these (and buy 5 at a time) is that they’re effectively identical (Optiplex 3040 micro form factor) and so should the power supply on one die, I don’t need to dig, it’s obvious where to get spare parts from.

Another con: no BIOS updates, it’s long out-of-support.

micro remote servers:

1- In one office, it primarily runs the “UniFi Network Application” to coordinate and update the Ubiquiti UniFi access points installed there. On the side, smokeping and prometheus (collecting router SNMP) to monitor the general network health. The thing is a java app, and trying to run it in 1 GB of RAM is nearly impossible, so the first gen intel stick failed at that task. For this, RAM is essentially free (i.e. DDR3, nobody wants it anymore, but also the machines come with 8 GB which leaves plenty free; no swap needed)
2- There’s my personal offsite backup as mentioned
3- “Dial home device” in another office. It has a dynamic IP, so this is the most reliable way for me to access their network.
4- tiny application server for a convention I volunteer at. We come in, set up, run for a week, then pack up and go away. It’s custom Python backed by MySQL running at a peak of 5 QPS for 10 seconds then nothing for minutes. The main need here is compact and easy to transport, but code-wise it’s trivial. The last system was a Dual Core era machine (pre Core-i\d) that I only upgraded like 2 years ago, as proof that performance really doesn’t matter much.

Of the two batches of 5 that I bought, the actual CPU from my notes:
Intel Core i3-6100T CPU @ 3.20GHz; 2c/4t
Intel Core i5-6500T CPU @ 2.5 GHz; 4c/4t
which I would generically hand wave at cpubenchmark.net for comparisons. For example: Intel Core i3-6100T @ 3.20GHz vs Intel Core i5-6500T @ 2.50GHz vs Intel N100 [cpubenchmark.net] by PassMark Software but that’s the performance for all cores. Most of the stuff I care about honestly is typically single core performance.

However, yes, I will benchmark the stats not available such as idle and 100% cpu busy wattage. I need those for my notes anyways.

None of that stuff sounds in the slightest bit CPU limited. I’m curious as to what you find the Pentium/Celeron stuff too slow for.

Sorry for the delay. After rearranging my “PC lab”, I found I didn’t have a HDMI monitor, only a VGA one. Took awhile to haul one out of storage.

CPU under test: Intel(R) Core™ i3-6100T CPU @ 3.20GHz 2c/4t with a SSD

According to my “Watts Up?” meter, the box momentarily blips up to 34W during boot, idles at 8W with Ubuntu 22 with zero modifications to the stock server install. no GUI, just a text console/getty. Caveat: the Watts Up isn’t as accurate as other units below 15W. Running ong gzip -9 reports 20W. two gzip-9’s report 30W. four gzip-9’s reports ~35W.

My last experience with CPUs below Core i3 was the Atom Z3735F in the first “Intel Stick”. It feels sluggish for things like installing the OS, running updates. I actively run 3 of these; two for Octoprint and one for a a control system for a 12x12 audio matrix (mixer) controlled via rs232 serial, with user controls (vol +/-) via python http server. The appeal with the Intel Stick is compactness (about half the size of a RPi).

I have issues with the RPi, primarily cabling sticking out of 3 sides. If I want to make a physical box to contain it, have all the connectors on one or two sides for compactness (vs current 3-4!), but still expose at least one USB and HDMI to exterior bulkhead connectors for diagnostic purposes… that gets expensive fast; bulkhead pigtails run about $10 each.

1 Like

Well, I just learned some very important and potentially useful things about UEFI, booting, NVRAM, Qubes, and the H3 series (but this should apply to other systems as well).

Goal: Swap SSD from H3+ to H3, carry on with life. Result: H3 steadfastly refuses to admit that there’s anything bootable on the SSD. Fiddle with settings in the BIOS, no changes. Ok. Deeper dive, it is.

EFI partitions have assorted directories - you’ll typically find things like /EFI/BOOT or /EFI/UBUNTU or such floating around. For most firmware, there are some default paths like /EFI/BOOT where it will look for things if it can’t find anything else.

Qubes uses the non-standard /EFI/QUBES path - which is fine. The installer puts things there, and then, importantly, tells the firmware that “Hey, there’s a bootable thing over here, you should look for it and see if it’ll boot.” This is stored in the NVRAM variables, which are per-hardware-instance - if you swap between two identical mainboards, or, say, an H3 and H3+, the NVRAM variables follow the board, not the SSD. And this was the root of my problem - the H3 didn’t know to look for things over in the boot path Qubes set up.

A reinstall would have fixed it, but that’s annoying. Fortunately, there are a few other handy things I learned.

If you have a Linux USB boot drive that will get to grub, you can use “someone else’s grub config files” easily enough with the configfile command. Enter the command shell (‘c’), then something like configfile (hd1,gpt1)/efi/qubes/grub.cfg will load the grub.cfg menus and such from that other partition, not whatever you just loaded grub from. Handy-dandy to boot when the firmware won’t find your OS loader.

Once you’re in the OS, efibootmgr is your friend. You probably won’t see anything but the USB boot entry with efibootmgr -v (all of these need to be as root), so you’ll want to add the proper entry.

In my case, something like:

efibootmgr --create --disk /dev/nvme0n1 --part 1 --loader /EFI/QUBES/GRUBX64.EFI --label "QubesOS"

worked nicely, and the system rebooted properly afterwards.

And now I know more about the interaction between EFI, NVRAM, the /EFI partition, and booting!