TinyComputers.io (Posts about cortex-a76)

FriendlyElec NanoPC-T6N Review: The Fastest Board on My Bench, and the Benchmark That Outgrew Itself

A.C. Jokela — Wed, 29 Jul 2026 14:15:00 GMT

I reviewed the NanoPC-T6 back in March 2025, but that piece was a specification comparison - a paper exercise against the Raspberry Pi 5 and the Radxa X4. This time I have the hardware on my bench, in the form of FriendlyELEC's NanoPC-T6N, and I ran it through the same treatment every other board here gets: a from-clean Rust compile, three times, plus crypto, memory, storage, network, and thermal characterization.

The short version is that the T6N is the fastest ARM single-board computer I have benchmarked. It posted a 52.55-second mean clean release build, edging out the Orange Pi 5 Max - the previous ARM leader, and a board built on the same RK3588 silicon. It pushes over two gigabytes per second of AES-128-GCM. Under 120 seconds of eight-core stress it peaked at 56.4 °C and never dropped a single clock bin. For a board that has been shipping in one revision or another since 2023, the RK3588 is aging with remarkable grace.

But the more interesting thing I found had nothing to do with the board, and I want to lead with it because it changes how you should read every number below.

The Benchmark That Outgrew Itself

My standard SBC test is a clean cargo build --release of a ballistics simulation engine I maintain. Three runs, cargo clean between each, averaged. It is a good test because it is real work: it hammers the CPU, the memory subsystem, the storage, and the compiler all at once, and it is the kind of thing I actually do on these machines.

The problem is that the benchmark is a live project, and live projects grow.

When I ran the October 2025 fleet sweep that produced the comparison table I have been citing ever since - Orange Pi 5 Max at 62.31 s, Raspberry Pi CM5 at 71.04 s, Raspberry Pi 5 at 76.65 s - the engine was at commit 2821bba: 43 Rust source files, 16,639 lines of code, 13 direct dependencies. As of today, HEAD is edd333d: 158 source files, 117,002 lines, 281 crates in the resolved dependency graph. Seven times the code.

So when the T6N's first timed run came back at 353 seconds, I did not have a slow board. I had an invalid comparison. Against the current tree the T6N looks like it belongs down near the Cortex-A53 machines; against the tree every archived number was measured on, it is at the top of the table. Same board, same afternoon, same toolchain — a 6.66x difference that says nothing whatsoever about the hardware.

The fix was to check out 2821bba on the T6N and run the benchmark against the exact tree the fleet was measured on. Everything I present as a fleet comparison below uses that pinned tree. I am also reporting the current-tree number, because it is a genuinely useful data point about what a 2026-sized Rust project costs on this class of hardware — it is just not a number you can put in the same column as a 2025 result.

Two caveats I cannot engineer away. First, my run used rustc 1.97.1; the archived fleet runs used 1.90.0 and 1.91.0. Second, that commit predates the repository having a Cargo.lock, so dependency versions resolve fresh at build time and my build pulled newer crates than the October build did. Same source tree, different compiler, drifting dependencies. I would have preferred to re-run a reference board alongside the T6N under identical conditions, and I tried — but every candidate in my fleet was pinned under fuzzing jobs at load averages of 5 to 38, and a contaminated reference number is worse than an honest caveat. Treat the ~19% margin over the Orange Pi 5 Max as directional, not decisive. The safe claim is that the T6N is at the front of the pack, not that it has a measurable lead over its RK3588 sibling.

Hardware Architecture: The RK3588, Four Years On

The T6N is built on Rockchip's RK3588 - the device tree reports friendlyelec,nanopc-t6n / rockchip,rk3588, so this is the full RK3588, not the reduced-I/O RK3588S. It is an 8 nm big.LITTLE part that has become the default answer for "I want a fast ARM SBC," and it powers a large fraction of the boards on my shelf.

What lscpu reports on my unit is more specific than the marketing:

Cluster	Cores	Frequency range
Little	4x Cortex-A55 (r2p0)	408 - 1800 MHz
Big, cluster 0 (cpu4-5)	2x Cortex-A76 (r4p0)	408 - 2304 MHz
Big, cluster 1 (cpu6-7)	2x Cortex-A76 (r4p0)	408 - 2352 MHz

The RK3588 is usually advertised at "up to 2.4 GHz." The operating point tables in this image top out at 2304 MHz on one big cluster and 2352 MHz on the other — a real asymmetry, visible in scaling_available_frequencies, and the sort of thing you only see when you go looking. It is not a defect; RK3588 splits its four A76s into two dual-core clusters with independent DVFS, and per-cluster binning is normal. It does mean the headline clock is a rounding-up.

Cache is generous: 384 KiB L1d and 384 KiB L1i across eight instances, 2.5 MiB of L2, and 3 MiB of shared L3. The full ARMv8 crypto feature set is present — aes, pmull, sha1, sha2, crc32, plus asimddp (dot product) and fphp/asimdhp (half-precision) — and as the crypto section shows, those instructions are doing real work.

My unit carries 16 GB of LPDDR4X (15 GiB usable after the kernel and GPU carve-outs) with no swap configured, and a 64 GB eMMC module. Alongside the CPU sit the parts that make an RK3588 more than a CPU:

A Mali-G610 GPU (mali fb000000.gpu, kernel DDK g29p0-00eac0), idling at 300 MHz against a 1000 MHz ceiling.
A 6 TOPS NPU across three cores (fdab0000.npu), with its devfreq pinned at 1000 MHz.
Two RKVENC encoder cores plus the Rockchip MPP video stack.
Three 2D acceleration engines — dual RGA3 (hw_version 3.0.76831) and one RGA2 (3.2.63318).
A hardware crypto engine exposed through the rk_crypto and cryptodev kernel modules.

A note on the model name: I could not find authoritative public documentation for the "T6N" suffix specifically. FriendlyELEC's public pages cover the NanoPC-T6, the T6 LTS, and the newer T6 Plus (which moves to LPDDR5). Both /proc/device-tree/compatible and /etc/friendlyelec-release on my board say NanoPC-T6N unambiguously, and everything I measured is consistent with the T6 family's RK3588 platform. Where I cite a port or interface I did not personally exercise, I flag it as a vendor specification for the T6 family rather than something I verified.

The Board As Configured

Physically the T6 family is a 110 x 80 mm eight-layer board — noticeably larger than a Raspberry Pi's 85 x 56 mm footprint, and denser with I/O. The headline feature, and the reason to pick a T6 over an Orange Pi 5 Max, is dual 2.5-gigabit Ethernet. My unit has two Realtek RTL8125 controllers, each sitting behind its own PCIe bridge:

-[0002:20]---00.0-[21]----00.0  Realtek RTL8125 2.5GbE Controller
-[0004:40]---00.0-[41]----00.0  Realtek RTL8125 2.5GbE Controller

Both negotiate PCIe Gen 2 x1 links, which is the correct provisioning: 5 GT/s x1 is about 500 MB/s of usable bandwidth, comfortably above the 312 MB/s a saturated 2.5GbE link needs. The device tree exposes five PCIe controllers in total. Two carry the NICs. pcie@fe150000 — the PCIe 3.0 controller that feeds the M.2 M-key slot — spent boot cycling through LTSSM states and eventually logged PCIe Link Fail, which is exactly what an empty slot looks like. My unit has no NVMe installed, so I could not measure the board's fastest storage path, and I have not verified the M-key slot electrically.

The board came to me headless, reached over an attached JetKVM (visible in lsusb as a USB HID gadget), so the display side — two HDMI 2.1 outputs, the HDMI input that is the T6's genuinely unusual party trick, the dual MIPI-DSI and dual MIPI-CSI connectors — is vendor specification I did not exercise. /dev/dri/card0 is present and bound to the display subsystem, so the plumbing is there.

Storage: The Part That Bothered Me

Here is the configuration detail with the biggest practical consequence. The kernel command line reads storagemedia=sd, root=/dev/mmcblk0p8. Checking the block devices:

Device	Type	Model	Size	Role
`mmcblk0`	SD	SanDisk `SN64G`	59.5 GB	Boots and runs the system
`mmcblk2`	MMC	`A3A561`	57.6 GB	Onboard eMMC — populated, fully partitioned, unused

The board is running from a microSD card while a perfectly good 64 GB eMMC module sits idle underneath it. The root filesystem is an overlay (lowerdir=/root, upperdir=/data/root) on the SD card's partitions — FriendlyELEC's standard layout, just pointed at the wrong medium.

I measured what that costs, read-only on both devices so nothing was written to the eMMC:

Measurement	microSD (`mmcblk0`)	eMMC (`mmcblk2`)
Buffered disk read (`hdparm -t`)	64.85 MB/s	302.05 MB/s
Cached read (`hdparm -T`)	4,446 MB/s	6,878 MB/s
Filesystem write, 1 GB `dd conv=fdatasync`	54.6 MB/s	not tested (would require writing)
Filesystem read, 1 GB after cache drop	67.9 MB/s	not tested

The eMMC reads 4.66x faster than the card the system is booted from. The microSD is turning in respectable UHS-I numbers — 65 MB/s buffered read is about what SDR104 gives you — but it is the slowest component in an otherwise quick machine.

How much is it actually costing? Less than you would guess for the compile benchmark, and that is worth being precise about. Rust compilation is overwhelmingly CPU-bound once the dependency sources are on disk; the T6N still posted the fastest ARM time on my bench from a microSD. But the run-to-run standard deviation on the pinned tree was 2.27 s against a 52.55 s mean (4.3%), noticeably looser than the 1.4% I saw on the 350-second HEAD run, and the first run of each series was consistently the slowest — the signature of cold cache being refilled over a slow device. For workloads that are actually I/O-bound — a NAS, a container host, a database, anything doing bulk writes — the gap would be the whole story.

If you buy one of these, install to the eMMC, or better, populate the M.2 slot. I did not reflash my unit because the eMMC's partition table suggests something is installed there that is not mine to overwrite.

Software: FriendlyELEC's Debian 13 BSP

The board runs Debian GNU/Linux 13.3 (trixie) on kernel 6.1.141, built Sat Jul 18 2026. That combination deserves unpacking, because it is the standard Rockchip vendor-BSP bargain.

Trixie is genuinely current — a 2025 Debian stable with a modern userland, OpenSSL 3.5.6, and a package archive that has everything you would want. apt install build-essential git curl pkg-config libssl-dev worked without a hitch, and rustup installed rustc 1.97.1 with no drama. From userspace this feels like any other Debian machine.

The kernel does not. 6.1 is the Rockchip vendor tree, not mainline, and /etc/friendlyelec-release reports LINUXFAMILY=nanopi6, BRANCH=dev. The board firmware — ddr-v1.17, bl31-v1.56, bl32-v1.21, U-Boot dated 07/10/2026 — is recent, and a kernel built eleven days before I tested it says FriendlyELEC is actively maintaining this image. That is better vendor hygiene than most. But it is still a 6.1 vendor kernel, which means the NPU, the video codecs, and the GPU all depend on out-of-tree drivers and Rockchip's userspace libraries. Mainline RK3588 support has come a long way, and if you want it you can run Armbian or Debian with a mainline kernel — you will simply give up the accelerators.

The one thing that surprised me was the default CPU frequency governor: conservative. Not schedutil, not ondemand, not performance — conservative, which is the most cautious ramp-up policy in the kernel and an unusual default for a board sold on its performance. All six governors are available.

I assumed this was costing measurable throughput, so I tested it: three pinned-tree builds under conservative, three under performance, back to back on an otherwise idle board.

Governor	Run 1	Run 2	Run 3	Mean
`conservative` (shipped default)	55.00 s	51.28 s	54.18 s	53.49 s
`performance`	54.59 s	54.83 s	52.44 s	53.95 s

No difference — 0.9% in favor of the shipped default, comfortably inside the noise. I was wrong about this one, and the reason is straightforward: a sustained compile keeps every core busy, so even a conservative governor ramps to maximum within the first second and stays there. I confirmed the big cores sat at 2304 MHz throughout the performance runs and throughout sustained stress testing.

Where conservative could still bite you is bursty, latency-sensitive, interactive work — a desktop session, a request-response server with idle gaps — where the ramp-up delay lands inside the thing you care about. I did not measure that, so I will not claim it. For sustained compute, leave the default alone. (I restored the board to conservative after testing.)

Compile Performance

Three clean release builds, cargo clean between each, on an otherwise idle board.

Pinned tree (2821bba — 43 files, 16,639 LOC), the fleet-comparable workload:

Run 1: 55.17 s
Run 2: 51.42 s
Run 3: 51.07 s
Mean: 52.55 s (median 51.42 s, σ 2.27 s)

Current tree (edd333d — 158 files, 117,002 LOC, 281 crates):

Run 1: 353.36 s
Run 2: 352.23 s
Run 3: 344.19 s
Mean: 349.93 s (median 352.23 s, σ 5.00 s)

Left: the fleet on the pinned Sept-2025 tree. Right: the same board and toolchain against both sizes of the same project — 6.66x the build time for 7.03x the code.

Against the archived fleet, on the tree they were all measured against:

System	SoC / CPU	Cores	Mean	vs. T6N
NanoPC-T6N	RK3588 — 4x A76 + 4x A55	8	52.55 s	1.00x (baseline)
Orange Pi 5 Max	RK3588 — 4x A76 + 4x A55	8	62.31 s	1.19x slower
Raspberry Pi CM5	BCM2712 — 4x A76	4	71.04 s	1.35x slower
LattePanda IOTA	Intel N150	4	72.21 s	1.37x slower
Raspberry Pi 5	BCM2712 — 4x A76	4	76.65 s	1.46x slower
Banana Pi CM5-Pro	RK3576 — 4x A72 + 4x A53	8	167.15 s	3.18x slower
Horizon X3 CM	4x Cortex-A53	4	378.81 s	7.21x slower
Banana Pi R2 Pro	RK3568 — 4x A55	4	418.18 s	7.96x slower
Orange Pi RV2	Ky X1 — RISC-V	8	650.60 s	12.38x slower
Milk-V Mars	JH7110 — RISC-V, 4x U74	4	936.18 s	17.82x slower

Archived figures are from the October 2025 fleet sweep on rustc 1.90/1.91; the T6N figure is from July 2026 on rustc 1.97.1 against the same source tree. See the caveats above — the T6N's position at the top is solid, its exact margin is not.

The honest reading: the T6N belongs in the top tier, alongside the Orange Pi 5 Max and ahead of the four-core A76 machines. It should be ahead of the Orange Pi 5 Max on clocks alone — 2304/2352 MHz against the 5 Max's 2256 MHz is a 2-4% edge — and it had 16 GB of RAM and an idle system working for it. Whether the remaining margin is real silicon or compiler version, I cannot say from this data.

The 350-second figure on the current tree is the one to internalize if you are choosing hardware for real 2026 development work. A 117,000-line Rust project with 281 crates takes about six minutes to build from clean on the best ARM SBC I have. That is a coffee break, not a lunch break, and it is genuinely usable — but it is a different world from the sub-90-second numbers that made the 2025 table look so friendly.

CPU: Sysbench and Core Scaling

sysbench cpu --cpu-max-prime=20000, 15-second runs:

Threads	Events/sec	Scaling vs. 1 thread
1	967.41	1.00x
4 (big cluster width)	3,861.78	3.99x
8 (all cores)	5,324.94	5.50x

The four-thread result is the interesting one: 3.99x scaling on four threads is essentially perfect, which tells you the two big clusters are genuinely independent and the memory subsystem is not contending under parallel load. That is a well-built SoC.

Going from four threads to eight adds only 37.9%, not the 100% a naive core count would suggest. This is exactly what big.LITTLE is supposed to look like: the four A55s are efficiency cores, not performance cores, and on a compute-bound integer workload each contributes roughly a third of what an A76 does. It is not a disappointment — it is the design. Anyone sizing a workload should think of the RK3588 as "four fast cores plus useful background capacity," not "eight cores."

For comparison against the numbers in my Orange Pi 5 Max review: that piece reported 13,688 events/sec, but at sysbench's default --cpu-max-prime=10000. Doubling the prime limit roughly quarters the event rate, so the two figures are not comparable. Mine are all at 20000.

Cryptography

For a board with two 2.5-gigabit interfaces, crypto throughput determines whether it can serve as a VPN endpoint, a TLS terminator, or an encrypted NAS at line rate. OpenSSL 3.5.6, single thread, 16 KB blocks:

Algorithm	Throughput	Hardware accelerated?
AES-128-GCM	2,185.7 MB/s (~17.5 Gb/s)	Yes (ARMv8 AES + PMULL)
AES-128-CBC	1,831.8 MB/s (~14.7 Gb/s)	Yes
AES-256-GCM	1,763.9 MB/s (~14.1 Gb/s)	Yes
SHA-256	1,429.4 MB/s (~11.4 Gb/s)	Yes (ARMv8 SHA2)
ChaCha20-Poly1305	674.4 MB/s (~5.4 Gb/s)	No (software, NEON)
SHA-512	376.1 MB/s (~3.0 Gb/s)	No (no SHA-512 extension)
RSA-2048	269.6 sign/s, 9,828 verify/s	—
ECDSA P-256	16,917 sign/s, 5,072 verify/s	—

A single A76 core encrypts AES-128-GCM at 2.19 GB/s. Saturating one 2.5-gigabit port with authenticated encryption needs 312.5 MB/s; saturating both needs 625 MB/s. One core, with seven others idle, produces 3.5x what both ports combined can consume. Whatever else you throw at this board, crypto will not be the bottleneck.

The ChaCha20-Poly1305 line is worth dwelling on because it directly determines WireGuard performance — WireGuard uses ChaCha20-Poly1305 exclusively and there is no hardware acceleration for it on ARMv8. At 674 MB/s (~5.4 Gb/s) it runs 2.6x slower than AES-256-GCM. That is a much narrower gap than the 4x+ I measured on the Cortex-A73 in the Banana Pi BPI-R4 Pro — the A76's wider execution resources close a lot of it in software. At 5.4 Gb/s, a single core covers one 2.5GbE port more than twice over, and just clears the 5 Gb/s both ports can carry together — with seven more cores available if you need headroom. Unlike on the R4 Pro, WireGuard is a non-issue on this board.

ECDSA P-256 at 16,917 signatures/sec is far more TLS handshake capacity than this board will ever need. RSA-2048 signing at 269.6/sec is the weak spot in the table, but it is only a constraint for a busy public-facing web frontend using RSA certificates — use ECDSA and it evaporates.

rk_crypto and cryptodev are both loaded, meaning Rockchip's dedicated crypto engine is available in addition to the ARMv8 instructions. Every figure above is from the CPU instructions via OpenSSL's default provider; I did not route OpenSSL through the hardware engine, so the dedicated accelerator's throughput remains unmeasured.

Memory Bandwidth

sysbench memory with 1 MB blocks across 8 threads reported 58,114 MiB/s read and 55,902 MiB/s write.

Do not believe those numbers as DRAM bandwidth. A 64-bit LPDDR4X interface has a theoretical ceiling in the low tens of GB/s, and 58 GB/s exceeds what this memory controller can physically deliver. sysbench memory is well known to measure something closer to cache throughput and compiler-optimized memory operations than actual main-memory bandwidth. I am reporting the figures because they are what the standard tool produced and because they are a valid relative data point against other boards measured the same way — but I am not going to dress them up as a DRAM measurement, and neither should anyone else.

What I can say with confidence is the practical part: 16 GB is a lot of RAM for an SBC, the board never touched swap (there is none configured), and nothing I ran came close to memory pressure. The near-perfect four-thread sysbench CPU scaling is indirect evidence that the memory subsystem keeps up with the big cluster under load.

Network

iperf3 with four parallel streams between the T6N and another host on the same LAN segment:

Direction	Throughput
Board receives	944 Mb/s
Board transmits	936 Mb/s

Both directions hit gigabit line rate — 944 Mb/s with zero retransmissions on the receive path is about as clean as TCP over a 1 Gb link gets. The transmit path matched it at 936 Mb/s but logged 3,850 retransmissions across the four streams; I would not read much into that, since the peer on the other end was carrying a load average around 38 at the time.

The caveat is that this measures my wiring, not the board. eth1 negotiated at 1000 Mb/s, not 2.5 Gb/s, because the switch it is plugged into is a gigabit switch. eth0 had no link. The RTL8125 controllers are 2.5GbE parts on adequately-provisioned PCIe Gen 2 x1 links, so the silicon is there — I simply do not have the infrastructure to prove it, and I am not going to claim a 2.5-gigabit result I did not measure.

One driver quirk worth flagging for anyone debugging: the r8125 driver (version 9.016.01-NAPI-g61ed2fd) misreports its capabilities to ethtool, advertising Supported link modes: 10baseT/Half 10baseT/Full — obviously wrong for a 2.5GbE controller. The link negotiates correctly regardless; it is cosmetic, but it will confuse you if you are chasing a link-speed problem through ethtool output.

Thermals: The Best Result on the Board

I ran stress-ng --cpu 8 for 120 seconds, sampling every 10 seconds.

Elapsed	SoC	Big core 0	Big core 1	Big cluster clock	Little cluster clock
Idle	47.2 °C	48.1 °C	48.1 °C	—	—
10 s	54.5 °C	55.5 °C	55.5 °C	2304 MHz	1800 MHz
40 s	55.5 °C	56.4 °C	56.4 °C	2304 MHz	1800 MHz
70 s	55.5 °C	56.4 °C	57.3 °C	2304 MHz	1800 MHz
110 s	56.4 °C	57.3 °C	57.3 °C	2304 MHz	1800 MHz
+30 s cooldown	46.2 °C	—	—	408 MHz	—

Peak SoC temperature of 56.4 °C after two minutes of full eight-core load, with zero throttling. The big cores held 2304 MHz and the little cores held 1800 MHz for the entire run — not one clock bin dropped. The board shed the heat and returned to 46.2 °C within 30 seconds of the load ending. stress-ng recorded 149,890 bogo-ops at 1,248 bogo-ops/sec.

For context, RK3588 boards have a reputation for needing serious cooling, and thermal throttling under sustained load is a common complaint across the family. My unit shows none of it. A ~9 °C rise from idle to sustained full load means substantial headroom — the thermal solution on this board is doing its job with room to spare. If you are planning a sustained-compute deployment, this is the number that should reassure you.

Accelerators: What Is There, and What I Verified

I want to be careful here, because it is easy to inventory silicon and imply you benchmarked it.

What I verified is present and driver-bound:

The NPU is live. rknpu driver v0.9.8 is loaded, the devfreq node fdab0000.npu is pinned at 1000 MHz, and it is exposed as a DRM device — /dev/dri/card1 and /dev/dri/renderD129, symlinked from platform-fdab0000.npu-card. Note it is not at /dev/rknpu; if you are following an older tutorial expecting that path, this is why it seems missing.
/usr/lib/librknnrt.so ships in the image (7.2 MB, dated January 2026). FriendlyELEC including the RKNN runtime out of the box is a genuinely nice touch — on several other Rockchip boards I have had to source it myself. The Python rknnlite bindings are not installed; you will need to add those.
The Mali-G610 is bound (mali fb000000.gpu, DDK g29p0-00eac0) with devfreq from 300 MHz to 1000 MHz.
Video encode/decode is available through Rockchip's MPP stack — /dev/mpp_service and librockchip_mpp.so are present, and two RKVENC cores probed cleanly. Note there is no /dev/video*: this is not a V4L2 M2M interface, so anything expecting mainline-style hardware codecs will need the Rockchip libraries instead. That is a meaningful integration cost if your pipeline assumes V4L2.
All three RGA 2D engines probed successfully.

What I did not measure: NPU inference throughput. Running a meaningful RKLLM or RKNN benchmark requires converting models on an x86 host and building out the toolkit, which was outside the scope of this session. The T6N carries the same 6 TOPS NPU, the same three-core architecture, and the same driver generation as the Orange Pi 5 Max, so my existing RK3588 NPU benchmarks — TinyLlama 1.1B at 10-15 tokens/sec, ResNet18 at 244 FPS and 4.09 ms latency — should transfer closely. I am pointing at those rather than inventing numbers for this board.

Also unmeasured, for the record: NVMe performance (empty M.2 slot), 2.5-gigabit throughput (gigabit switch), GPU graphics performance (no glmark2/vulkaninfo installed, headless unit), HDMI input and output, and the MIPI DSI/CSI connectors.

Comparative Context

Against the Orange Pi 5 Max — the closest comparison, same SoC, same 16 GB. These boards are performance twins; treat my 19% margin as unproven. The real difference is I/O. The T6N has two 2.5GbE ports to the 5 Max's one, an HDMI input, and a larger 110 x 80 mm board with denser connectors. The 5 Max is a more conventional desktop-shaped SBC. If you want a router, firewall, NAS head, or anything that needs two fast network interfaces, the T6N is the obvious pick. If you want a small ARM desktop, the 5 Max is cheaper and gives up nothing important.

Against the Raspberry Pi 5 and CM5 — the T6N is roughly 1.35-1.46x faster on the compile benchmark, has twice the maximum RAM, adds a 6 TOPS NPU the Pi entirely lacks, and brings dual 2.5GbE against the Pi's single gigabit port. The Pi's counterargument is the one it always makes and always wins: ecosystem. Raspberry Pi OS is polished, mainline kernel support is a given, documentation is excellent, and the community is orders of magnitude larger. If you value never fighting your kernel over raw throughput, that trade is still worth making. If you have run vendor BSPs before and know what you are signing up for, the T6N is more machine.

Against the Banana Pi CM5-Pro (RK3576) — 3.18x faster on the compile benchmark. The RK3576's A72/A53 pairing is a genuine generation behind the RK3588's A76/A55. The CM5-Pro's case is the CM4-compatible compute-module form factor and a lower price; on performance there is no contest.

Against the Banana Pi BPI-R4 Pro — an instructive contrast, because both boards want to be network appliances from opposite directions. The R4 Pro is a router that computes adequately: 10-gigabit MACs, a hardware packet-processing engine, a switch, WiFi 7, OpenWRT, and a modest quad A73. The T6N is a computer that networks well: far more CPU, an NPU, a GPU, a full Debian userland, and two 2.5GbE ports with no hardware offload engine behind them. For line-rate routing at 10G, the R4 Pro wins on silicon designed for the job. For a firewall or gateway that also runs containers, does inference, or serves files, the T6N is the better foundation.

Against x86 — the LattePanda IOTA's Intel N150 came in at 72.21 s, about 1.37x behind. The T6N wins on compile throughput, RAM ceiling, NPU, and networking. x86 wins on software compatibility, mainline everything, and never having to think about device trees. And for a genuine sense of scale: the AMD AI Max+ 395 desktop in the same archived sweep did the pinned tree in 13.71 s, about 3.8x faster than the best ARM SBC on my bench. These boards are remarkable for their size and power envelope, not in absolute terms.

Use Cases and Recommendations

Choose the NanoPC-T6N if you:

Need two fast network interfaces on a capable compute platform. This is the core case. Dual 2.5GbE with a CPU that can encrypt at 2.19 GB/s and eight cores to spare makes an excellent firewall, gateway, VPN concentrator, or NAS head — one that also runs Docker, serves web applications, and does inference without breaking a sweat.

Want the fastest ARM SBC compile times available. On the pinned benchmark it is at the front of the field. For a headless ARM build box, CI runner, or development machine, this is the top of my bench.

Are doing edge AI with the Rockchip stack. 6 TOPS, three NPU cores, and librknnrt.so shipped in the image. If you have already invested in RKNN or RKLLM tooling, this is a well-provisioned host for it.

Need sustained load in a constrained thermal environment. 56.4 °C peak with zero throttling under full eight-core load is the best sustained-load result I have measured on an RK3588 board. Enclosed or fanless deployments are realistic.

Want 16 GB of RAM on an ARM SBC. Still uncommon, and it makes containers, large builds, and in-memory workloads comfortable.

Choose something else if you:

Want mainline kernel support and a hands-off experience. This is a 6.1 vendor BSP. The accelerators are out-of-tree, video is Rockchip MPP rather than V4L2, and you are dependent on FriendlyELEC's image cadence for the full feature set. A Raspberry Pi 5 will never make you think about any of this.

Are buying primarily for a desktop. The T6N is a headless-shaped board with router-grade I/O. An Orange Pi 5 Max costs less and does the desktop job as well. And I did not test the display path at all.

Need line-rate 10-gigabit routing. No hardware packet-processing engine, no switch, no SFP+ cages. The BPI-R4 Pro is built for that; the T6N is not.

Are cost-sensitive. The T6 family is priced above a Raspberry Pi, and the dual 2.5GbE, HDMI input, and dual M.2 slots are what you are paying for. If you will not use them, you are buying capability you do not need. (I do not have verified current pricing for the T6N specifically, so shop it before you commit.)

Want a beginner's first SBC. Vendor images, overlay root filesystems, out-of-tree NPU drivers, and a conservative governor default are all things that reward knowing what you are doing.

Build Quality and Physical Characteristics

The T6 family is a 110 x 80 mm board (eight-layer, per FriendlyELEC's specifications for the line), and the density shows — two Ethernet jacks, two M.2 slots, HDMI in and out, MIPI connectors, and header banks in a footprint only moderately larger than a Raspberry Pi. My unit arrived cleanly manufactured with no defects, has been stable through every benchmark I threw at it, and the thermal numbers indicate a competent cooling solution. Over several hours of sustained testing I saw no instability, no unexpected resets, and no kernel errors beyond the expected empty-M.2-slot PCIe link failures at boot.

Conclusion: The RK3588 Is Aging Well

The NanoPC-T6N is the best-performing ARM single-board computer on my bench, and the margins that matter are not the compile times — those put it in a statistical tie with the Orange Pi 5 Max, and I have been careful to say so. What separates it is the I/O: two 2.5-gigabit ports on properly-provisioned PCIe lanes, backed by a CPU that can encrypt at over two gigabytes per second and eight cores that never throttled once in my testing. That combination makes it something more interesting than a fast SBC. It makes it a credible small network appliance that happens to have a 6 TOPS NPU and 16 GB of RAM attached.

The RK3588 has been shipping since 2022, and in 2026 it remains competitive against everything I can put next to it. That says something about how good the part was and something less flattering about the pace of ARM SBC silicon since.

My complaints are configuration and ecosystem, not hardware. The unit came booting from a microSD card while a 64 GB eMMC module — 4.66x faster on reads — sat unused beneath it, which is a five-minute fix that ships wrong. The 6.1 vendor kernel means the accelerators live outside mainline and video runs through Rockchip's MPP stack rather than V4L2. The r8125 driver lies to ethtool. None of these are dealbreakers; all of them are the texture of living with a Rockchip vendor BSP, and they are the same texture you will find on every board in this family.

The thing I will carry forward from this review, though, is not about the T6N at all. It is that my benchmark grew seven times larger while I was busy citing its old numbers, and I nearly published a result showing an excellent board as a mediocre one. A benchmark that tracks a live project stops being a benchmark the moment the project changes. From here on, the fleet comparison runs against a pinned tree, and I will be re-running the fleet on the current one to build a table that means something in 2026.

Specifications Summary

Processor (measured):

Rockchip RK3588 (rockchip,rk3588), 8 nm, aarch64
4x Cortex-A76 (r4p0): cpu4-5 up to 2304 MHz, cpu6-7 up to 2352 MHz
4x Cortex-A55 (r2p0): up to 1800 MHz
L1 384 KiB d + 384 KiB i (8 instances), L2 2.5 MiB, L3 3 MiB shared
ARMv8 crypto: aes, pmull, sha1, sha2, crc32; also asimddp, fphp, asimdhp

Memory & Storage (as tested):

16 GB LPDDR4X (15 GiB usable), no swap
64 GB microSD (SanDisk SN64G) — the boot and root device on my unit
64 GB onboard eMMC (A3A561) — present, partitioned, unused for boot
M.2 M-key slot (pcie@fe150000, PCIe 3.0) — empty on my unit, untested
Root on overlayfs (lowerdir=/root, upperdir=/data/root)

Networking (measured):

2x Realtek RTL8125 2.5GbE, each on its own PCIe Gen 2 x1 link
Driver r8125 9.016.01-NAPI-g61ed2fd (misreports link modes to ethtool)
eth1 negotiated 1000 Mb/s on my gigabit switch; 2.5G capability untested

Accelerators (present, inference throughput untested):

NPU: 6 TOPS, 3 cores, rknpu v0.9.8, devfreq 1000 MHz, DRM node /dev/dri/card1
librknnrt.so 7.2 MB shipped in image; rknnlite Python bindings not installed
GPU: Mali-G610, DDK g29p0-00eac0, 300-1000 MHz
Video: 2x RKVENC cores, /dev/mpp_service, librockchip_mpp.so (no V4L2 /dev/video*)
2D: 2x RGA3 (3.0.76831) + 1x RGA2 (3.2.63318)
Crypto: rk_crypto + cryptodev modules loaded (dedicated engine untested)

Software (as shipped):

Debian GNU/Linux 13.3 (trixie), kernel 6.1.141 built 2026-07-18 (FriendlyELEC BSP, LINUXFAMILY=nanopi6)
Firmware: ddr-v1.17, bl31-v1.56, bl32-v1.21, U-Boot 07/10/2026
OpenSSL 3.5.6; default CPU governor conservative
Toolchain installed for testing: rustc/cargo 1.97.1

Benchmark Results:

Rust clean release build, pinned tree (2821bba, 16,639 LOC): 52.55 s mean (σ 2.27 s) — fastest ARM board on my bench
Rust clean release build, current tree (edd333d, 117,002 LOC, 281 crates): 349.93 s mean (σ 5.00 s)
Governor conservative vs performance: 53.49 s vs 53.95 s — no meaningful difference
sysbench CPU (--cpu-max-prime=20000): 967 / 3,862 / 5,325 events per sec at 1 / 4 / 8 threads (3.99x scaling on the big cluster)
AES-128-GCM 2,185.7 MB/s; AES-256-GCM 1,763.9 MB/s; SHA-256 1,429.4 MB/s; ChaCha20-Poly1305 674.4 MB/s
ECDSA P-256 16,917 sign/s; RSA-2048 269.6 sign/s, 9,828 verify/s
Storage read: microSD 64.85 MB/s vs onboard eMMC 302.05 MB/s (4.66x)
iperf3: 944 Mb/s receive, 936 Mb/s transmit (gigabit-limited wiring)
Thermals: 47.2 °C idle, 56.4 °C peak under 120 s of eight-core load, zero throttling

Recommendation: The strongest general-purpose ARM SBC I have benchmarked, and an unusually good foundation for a compute-capable network appliance. Install it to eMMC or NVMe, and know you are buying into a Rockchip vendor BSP.

Review Date: July 29, 2026

Hardware Tested: FriendlyElec NanoPC-T6N (Rockchip RK3588) with 16 GB LPDDR4X, 64 GB eMMC, booted from 64 GB microSD, dual RTL8125 2.5GbE

OS Tested: Debian GNU/Linux 13.3 (trixie), kernel 6.1.141 (FriendlyELEC BSP, built 2026-07-18)

Benchmark Workload: ballistics-engine clean release builds at commits 2821bba (fleet-comparable) and edd333d (current), rustc 1.97.1

Conclusion: The RK3588 remains competitive four years on, and the T6N is its best expression on my bench — fast, cool, and unusually well-connected, held back only by a vendor BSP and a boot medium that should have been the eMMC.

Raspberry Pi Compute Module 5 Review: Performance Analysis and CM4-Compatible Ecosystem Comparison

A.C. Jokela — Tue, 23 Sep 2025 20:58:22 GMT

Comprehensive Performance Analysis: Raspberry Pi Compute Module 5 vs Orange Pi 5 Max and CM4-Compatible Alternatives

Executive Summary

This comprehensive benchmark analysis evaluates the performance characteristics of the Raspberry Pi Compute Module 5 (CM5) against the Orange Pi 5 Max and various CM4-compatible alternatives, representing diverse approaches to ARM-based compute module design. The RPi CM5, featuring a quad-core Cortex-A76 processor at 2.4GHz, demonstrates a remarkable generational leap from the CM4's Cortex-A72 architecture, achieving nearly 5x the single-core performance and 4.5x the multi-core performance of its predecessor. While the Orange Pi 5 Max, powered by the Rockchip RK3588's big.LITTLE architecture with eight cores, showcases superior multi-threaded capabilities and specialized AI acceleration through its integrated NPU.

Our testing reveals that while the Orange Pi 5 Max achieves approximately 3.3x better multi-threaded CPU performance and features dedicated AI processing capabilities, the Raspberry Pi CM5 counters with superior per-core performance efficiency, better thermal characteristics, and the backing of a mature ecosystem. When compared to the broader CM4-compatible module landscape including alternatives like the Banana Pi CM4 (Amlogic A311D), Radxa CM3 (RK3566), Pine64 SOQuartz, and the budget-oriented BigTreeTech CB1, the CM5 stands out for its balanced performance profile and ecosystem maturity. These findings position each platform for distinct use cases: the CM5 excels in industrial applications requiring reliability and ecosystem support, while the Orange Pi 5 Max targets compute-intensive and AI-accelerated workloads, and budget alternatives serve specific niches like 3D printing control.

Test Methodology

Testing Environment

Raspberry Pi CM5: Running Debian 12 (Bookworm) with kernel 6.12.25+rpt-rpi-2712
Orange Pi 5 Max: Running Armbian 25.11.0-trunk.208 with kernel 6.1.115-vendor-rk35xx
Test Suite: Sysbench 1.0.20, stress-ng 0.15.06, custom bandwidth tests, Geekbench 6
Testing Protocol: All tests conducted under controlled conditions with ambient temperature monitoring

Hardware Specifications Comparison

Raspberry Pi Compute Module 5 installed on the WaveShare CM5-PoE-BASE-A carrier board featuring dual HDMI, USB 3.0, and PoE support

Close-up view of the CM5 module showing the BCM2712 SoC, LPDDR4X memory, and high-density connectors

Specification	Raspberry Pi CM5	Raspberry Pi CM4	Orange Pi 5 Max	Banana Pi CM4
SoC	Broadcom BCM2712	Broadcom BCM2711	Rockchip RK3588	Amlogic A311D
CPU Architecture	4x Cortex-A76 @ 2.4GHz	4x Cortex-A72 @ 1.5GHz	4x A76 @ 2.26GHz + 4x A55 @ 1.8GHz	4x A73 + 2x A53
Process Node	16nm FinFET	28nm	8nm	12nm
RAM	16GB LPDDR4X	1-8GB LPDDR4	16GB LPDDR4X	4GB LPDDR4
L1 Cache	256KB I + 256KB D	48KB I + 32KB D	384KB I + 384KB D	Variable
L2 Cache	2MB (512KB per core)	1MB shared	2.5MB total	1MB + 512KB
L3 Cache	2MB shared	None	3MB shared	None
GPU	VideoCore VII	VideoCore VI	ARM Mali-G610 MP4	Mali-G52 MP4
NPU	None	None	6 TOPS RK3588 NPU	5 TOPS NPU
PCIe	PCIe 3.0 x1	PCIe 2.0 x1	PCIe 3.0 x4	PCIe 2.0 x1
Storage Interface	NVMe via HAT	eMMC/SD	Native M.2 NVMe	eMMC/SD
Power Consumption	8-10W	~7W	15-20W	~8W
Price (USD)	~$90-120	~$65	~$130-160	~$110

CM4-Compatible Module Landscape

Module	SoC	CPU	GB Single	GB Multi	Price	Best For
RPi CM4	BCM2711	4x A72 @ 1.5GHz	228	644	$65	General purpose
RPi CM5	BCM2712	4x A76 @ 2.4GHz	1081	2888	$90-120	High performance
Banana Pi CM4	A311D	4x A73 + 2x A53	295	1087	$110	AI/ML tasks
Radxa CM3	RK3566	4x A55 @ 2.0GHz	163	508	$69	Basic computing
Pine64 SOQuartz	RK3566	4x A55 @ 1.8GHz	156	491	$49	Low power
BigTreeTech CB1	H616	4x A53 @ 1.5GHz	91	295	$40	3D printing

Evolution from CM4 to CM5: A Generational Leap

The transition from Raspberry Pi CM4 to CM5 represents one of the most significant performance improvements in the Compute Module series history:

Performance Improvements

Single-Core Performance: 4.74x improvement (228 → 1,081 Geekbench score)
Multi-Core Performance: 4.48x improvement (644 → 2,888 Geekbench score)
Architecture Advancement: Cortex-A72 (CM4) → Cortex-A76 (CM5)
Clock Speed: 60% increase (1.5GHz → 2.4GHz)
Process Node: 16nm (CM5) vs 28nm (CM4), improving efficiency
Cache Hierarchy: Addition of 2MB L3 cache, larger L1/L2 caches
Memory Bandwidth: Significant improvement with LPDDR4X support

This generational leap places the CM5 well ahead of all CM4-compatible alternatives currently on the market, with only the Banana Pi CM4's Amlogic A311D offering somewhat competitive performance at 1,087 multi-core score, still falling far short of the CM5's capabilities.

CPU Performance Analysis

Single-Threaded Performance

The Raspberry Pi CM5 demonstrates remarkable single-threaded efficiency, achieving 1,035 events per second in Sysbench CPU tests. When compared across the compute module landscape:

Geekbench Single-Core Scores:

RPi CM5: 1,081 (reference)
OPi 5 Max: ~1,300 (estimated, not CM4-compatible)
Banana Pi CM4: 295 (27% of CM5)
RPi CM4: 228 (21% of CM5)
Radxa CM3: 163 (15% of CM5)
Pine64 SOQuartz: 156 (14% of CM5)
BigTreeTech CB1: 91 (8% of CM5)

The CM5's Cortex-A76 cores running at 2.4GHz provide exceptional single-threaded performance, outclassing all CM4-compatible alternatives by significant margins. Even the Banana Pi CM4 with its heterogeneous A73+A53 design achieves only 27% of the CM5's single-core performance. This efficiency becomes particularly evident in workloads that cannot be parallelized, such as JavaScript execution, compilation of single files, and legacy applications.

Multi-Threaded Performance

Multi-threaded benchmarks reveal the Orange Pi 5 Max's architectural advantage:

Sysbench CPU Multi-thread:
RPi CM5 (4 threads): 4,155 events/sec
OPi 5 Max (8 threads): 13,689 events/sec
Performance ratio: 3.3x advantage for Orange Pi
Geekbench 6 Multi-core:
RPi CM5: 2,888 points
OPi 5 Max: ~5,200 points (estimated)
Performance ratio: 1.8x advantage for Orange Pi

The Orange Pi's big.LITTLE architecture efficiently distributes workloads between high-performance A76 cores and efficiency-focused A55 cores, achieving superior throughput in parallel workloads while maintaining power efficiency during light tasks.

Matrix Operations Performance

Stress-ng matrix multiplication benchmarks highlight computational throughput differences:

Raspberry Pi CM5:

Add operations: 1,127 ops/sec
Multiply operations: 2,891 ops/sec
Division operations: 2,222 ops/sec
Transpose operations: 413 ops/sec

Orange Pi 5 Max:

Multiply operations: 228.98 ops/sec (product matrix)
Performance varies significantly based on matrix size and optimization

The CM5 shows consistent performance across different matrix operations, while the Orange Pi demonstrates variable performance depending on workload distribution across its heterogeneous cores.

Memory Performance

Bandwidth Analysis

Memory bandwidth tests reveal significant architectural differences:

Raspberry Pi CM5:

Sysbench memory (1KB blocks): 3.58 GB/s single-thread
Sysbench memory (4KB blocks, 4 threads): 24.3 GB/s
DD memory copy: 5.4 GB/s read

Orange Pi 5 Max:

Localhost iperf3: 40.1 GB/s (memory-to-memory)
Simple bandwidth test: 0.10 GB/s (methodology unclear)
Effective bandwidth varies with access patterns

The Orange Pi 5 Max demonstrates superior theoretical memory bandwidth, achieving 65% higher throughput in synthetic tests. However, real-world application performance depends heavily on memory access patterns and cache utilization.

Cache Hierarchy Impact

The Orange Pi's larger cache hierarchy (3MB L3 vs 2MB) provides advantages in data-intensive workloads: - Reduced memory latency for frequently accessed data - Better performance in database operations - Improved efficiency in content delivery applications

Storage Performance

Sequential Write Performance

Storage benchmarks reveal dramatic differences in I/O capabilities:

Raspberry Pi CM5:

SD Card write: 26.5 MB/s
NVMe write (via PCIe): 385 MB/s
SD Card read: 5.5 GB/s (cached)

Orange Pi 5 Max:

eMMC write: 2.1 GB/s
NVMe native interface: Up to 3.5 GB/s capable
Consistent performance across operations

The Orange Pi's native M.2 interface and PCIe 3.0 x4 connectivity provide a 5.5x advantage in storage throughput, critical for applications requiring high-speed data access such as video editing, databases, and content servers.

Random I/O Performance

While sequential performance favors the Orange Pi, the Raspberry Pi CM5's optimized kernel and drivers provide competitive random I/O performance, particularly important for:

Operating system responsiveness
Database transaction processing
Container deployment scenarios

GPU and Graphics Capabilities

Graphics Architecture Comparison

Raspberry Pi CM5 - VideoCore VII:

Vulkan 1.3 support
H.265 4K60 decode
Dual 4K display output
OpenGL ES 3.1 compliance
Mature driver support in mainline kernel

Orange Pi 5 Max - Mali-G610 MP4:

Vulkan 1.3 support
OpenGL ES 3.2
8K video decode capability
Panfrost open-source driver development
Superior compute shader performance

The Orange Pi's Mali-G610 provides approximately 2x the theoretical graphics performance, beneficial for:

GPU-accelerated compute workloads
Modern gaming emulation
Hardware-accelerated video processing
Computer vision applications

AI and NPU Capabilities

Neural Processing Comparison

The Orange Pi 5 Max's integrated 6 TOPS NPU represents a significant differentiator:

Orange Pi 5 Max NPU Performance:

TinyLLaMA inference: 20.2 tokens/second
NPU frequency: 1000 MHz
Power-efficient AI inference
Support for INT8/INT16 quantized models
RKNN toolkit compatibility

Raspberry Pi CM5 AI Options:

CPU-based inference only
External accelerators via PCIe/USB
Software optimization required
Higher power consumption for AI tasks

For AI-centric applications, the Orange Pi provides:

10-50x better inference performance per watt
Native support for popular frameworks
Real-time object detection capabilities
Efficient LLM inference for edge applications

Thermal Performance and Power Efficiency

Thermal Characteristics

Temperature monitoring under load reveals excellent thermal management:

Raspberry Pi CM5:

Idle temperature: 46.9°C
Load temperature (5s): 55.1°C
Peak temperature (25s): 56.2°C
Cooldown (10s after): 51.3°C
Temperature rise: 9.3°C under full load

Orange Pi 5 Max:

Idle temperature: 66.5°C
Load temperature: 67.5°C
Temperature rise: 1°C under load (with active cooling)

The Raspberry Pi CM5 demonstrates superior thermal efficiency with passive cooling, maintaining safe operating temperatures without throttling. The Orange Pi requires active cooling to maintain its higher performance levels, adding complexity and potential failure points.

Power Consumption Analysis

Raspberry Pi CM5:

Core voltage: 0.786V at 1.7GHz
Estimated idle power: 2-3W
Full load power: 8-10W
Excellent performance per watt

Orange Pi 5 Max:

Higher idle power: 5-7W
Full load power: 15-20W
NPU adds minimal overhead when active

The CM5's superior power efficiency makes it ideal for:

Battery-powered applications
Passive cooling designs
Dense computing clusters
IoT edge deployments

Software Ecosystem and Support

Operating System Support

Raspberry Pi CM5:

Official Raspberry Pi OS with long-term support
Mainline kernel support
Ubuntu, Fedora, and numerous distributions
Real-time kernel options available
Consistent update cycle

Orange Pi 5 Max:

Armbian community support
Vendor-specific kernel (6.1.115)
Limited mainline kernel support
Fewer distribution options
Dependent on community maintenance

Development Environment

The Raspberry Pi ecosystem provides superior developer experience:

Comprehensive documentation
Extensive tutorials and examples
Active community forums
Professional support options
Guaranteed long-term availability

CM4-Compatible Alternatives Analysis

Budget-Conscious Options

BigTreeTech CB1 ($40) The BigTreeTech CB1 represents the most affordable CM4-compatible option, built around the Allwinner H616 with quad-core Cortex-A53 processors. Despite its underwhelming Geekbench scores (91 single, 295 multi), it serves specific niches effectively:

3D Printing Control: Native OctoPrint/Klipper support
Basic HDMI Streaming: Capable of 4K 60fps video output
Low-Compute Tasks: Home automation, basic servers
Limitations: Only 1GB RAM, 100Mbit networking, lowest performance tier

Pine64 SOQuartz ($49) Offering slightly better value, the SOQuartz uses the RK3566 with more modern Cortex-A55 cores:

Power Efficiency: Only 2W power consumption
Better Memory Options: Up to 8GB LPDDR4
Improved Performance: 70% better than CB1
Use Cases: IoT gateways, low-power servers, battery-powered applications

Mid-Range Alternatives

Radxa CM3 ($69) The Radxa CM3 offers a balanced middle ground with the RK3566:

Performance: Similar to SOQuartz but at 2.0GHz
Connectivity: Better I/O options than budget boards
Software Support: Growing Armbian and vendor support
Best For: Light desktop use, media centers, network appliances

Banana Pi CM4 ($110) The premium alternative featuring Amlogic A311D with heterogeneous architecture:

NPU Acceleration: 5 TOPS AI performance
Strong Multi-Core: 1,087 Geekbench score
Video Processing: Excellent codec support
Ideal For: AI inference, video transcoding, edge ML applications

Performance vs Price Analysis

Module	Price	Performance/Dollar*	Power Efficiency**	Ecosystem
BigTreeTech CB1	$40	7.4	Good	Limited
Pine64 SOQuartz	$49	10.0	Excellent	Growing
RPi CM4	$65	9.9	Good	Excellent
Radxa CM3	$69	7.4	Good	Moderate
RPi CM5	$105	27.5	Very Good	Excellent
Banana Pi CM4	$110	9.9	Moderate	Limited

Based on Geekbench multi-core score per dollar *Relative rating based on performance per watt

Use Case Recommendations

Raspberry Pi CM5 Optimal Applications

Industrial Automation
Reliable long-term operation
Predictable thermal behavior
Extensive I/O options
Real-time capabilities
Edge Computing
Low power consumption
Compact form factor
Sufficient performance for most tasks
Strong ecosystem support
Educational Projects
Comprehensive learning resources
Consistent platform behavior
Wide software compatibility
Active community support
Prototype Development
Rapid deployment capabilities
Extensive peripheral support
Mature development tools
Easy transition to production

Orange Pi 5 Max Optimal Applications

AI and Machine Learning
Native NPU acceleration
High memory bandwidth
Efficient inference capabilities
Support for modern frameworks
Media Processing
8K video decode support
Multiple stream handling
Hardware acceleration
High storage throughput
High-Performance Computing
8-core processing power
Superior memory bandwidth
Fast storage interface
Parallel processing capabilities
Network Appliances
Multiple network interfaces possible
High packet processing rates
Sufficient compute for encryption
Container orchestration platforms

Performance Index Comparison

Creating a normalized performance index (RPi CM5 = 100):

Metric	RPi CM5	Orange Pi 5 Max
Single-thread CPU	100	120
Multi-thread CPU	100	330
Memory Bandwidth	100	165
Storage Speed	100	545
GPU Performance	100	200
AI Inference	100	1000+
Power Efficiency	100	60
Thermal Efficiency	100	70
Ecosystem Maturity	100	40
Overall Weighted	100	195

Cost-Benefit Analysis

Total Cost of Ownership

Raspberry Pi CM5:

Module cost: ~$90-120
Carrier board: $30-200
Cooling: Passive sufficient ($5-10)
Power supply: 15W ($10-15)
TCO advantage: Lower operational costs

Orange Pi 5 Max:

Board cost: ~$130-160
Active cooling required: $15-25
Power supply: 30W+ ($15-20)
Higher replacement rate expected
Performance advantage: Better compute per dollar

Value Proposition

The Raspberry Pi CM5 offers superior value for:

Long-term deployments (5+ years)
Applications requiring stability
Projects with limited thermal budgets
Scenarios requiring extensive documentation

The Orange Pi 5 Max provides better value for:

Compute-intensive applications
AI/ML workloads
Media processing systems
Performance-critical deployments

Future Outlook and Conclusions

Technology Trajectory

Both platforms represent different philosophies in ARM computing evolution:

Raspberry Pi CM5 continues the tradition of:

Incremental performance improvements
Ecosystem stability and compatibility
Power efficiency optimization
Broad market appeal

Orange Pi 5 Max demonstrates:

Aggressive performance scaling
Specialized acceleration (NPU)
Advanced process technology adoption
Focused market segmentation

Final Recommendations

Choose Raspberry Pi CM5 when:

Reliability and support are paramount
Power consumption must be minimized
Passive cooling is required
Software compatibility is critical
Long-term availability is needed

Choose Orange Pi 5 Max when:

Maximum performance is required
AI acceleration is beneficial
Multi-threaded performance is critical
Storage throughput is important
Cost per compute is the primary metric

Conclusion

The comprehensive analysis of the Raspberry Pi Compute Module 5, Orange Pi 5 Max, and the broader CM4-compatible module ecosystem reveals a rapidly evolving landscape of ARM-based compute modules, each targeting specific market segments and use cases. The CM5's remarkable 4.7x single-core and 4.5x multi-core performance improvement over the CM4 represents a watershed moment in the Compute Module series, establishing a new performance benchmark that no current CM4-compatible alternative can match.

The benchmark results clearly demonstrate distinct market segmentation: The Raspberry Pi CM5 dominates the high-performance compute module space with its 2.4GHz Cortex-A76 cores, achieving 1,081 single-core and 2,888 multi-core Geekbench scores while maintaining exceptional thermal efficiency at just 8-10W. This performance leadership comes at a premium but delivers unmatched value at 27.5 performance points per dollar. The Orange Pi 5 Max, while not CM4-compatible, showcases the potential of heterogeneous computing with its 8-core RK3588 and integrated 6 TOPS NPU, achieving 3.3x better multi-threaded performance for specialized workloads.

Among CM4-compatible alternatives, each module serves distinct niches: The BigTreeTech CB1 at $40 provides an ultra-budget option for 3D printing and basic automation, despite its limited 91/295 Geekbench scores. The Pine64 SOQuartz excels in power efficiency at just 2W consumption, ideal for battery-powered and IoT applications. The Radxa CM3 offers a balanced middle ground, while the Banana Pi CM4 stands out with its 5 TOPS NPU for AI applications, though still achieving only 38% of the CM5's multi-core performance.

For system integrators and developers, the choice depends on specific requirements: The CM5's combination of performance leadership, ecosystem maturity, and long-term support makes it the obvious choice for professional deployments where performance and reliability are paramount. Budget-conscious projects can leverage alternatives like the SOQuartz or CB1, accepting performance compromises for significant cost savings. The Banana Pi CM4 fills a unique niche for edge AI applications requiring NPU acceleration without the CM5's performance tier.

Looking forward, the CM5 sets a new standard that will likely drive innovation across the entire compute module ecosystem. Its performance leap from the CM4 demonstrates that ARM-based modules can now handle workloads previously reserved for x86 systems, while maintaining the power efficiency, compact form factor, and cost advantages that make them attractive for embedded applications. As competitors respond to this challenge and new process nodes become accessible, we can expect continued rapid evolution in this space, ultimately benefiting developers with more powerful, efficient, and specialized compute module options for diverse edge computing applications.