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.

TinyComputers.io (Posts about 2.5 gigabit ethernet)