The MangoPi MQ Pro compiles the pinned benchmark in 7,824 seconds, two hours and ten minutes, which is 149x the fleet leader and dead last of twelve boards. But the interesting numbers are elsewhere: per core it is only 4.2x behind a SiFive U74, its 486 MB of RAM never became the bottleneck because being single-core kept peak memory to one rustc, and getting Rust onto it at all required a Debian chroot because OpenWrt is musl and rustup ships no musl-hosted compiler.
The Pine64 Star64 runs StarFive's JH7110 - four SiFive U74 cores and an ISA string of rv64imafdc, which is RV64GC baseline and nothing more. It compiles Rust in 461 seconds, tenth of eleven on my bench, beating the Orange Pi RV2 with half the cores, matching its own JH7110 twin the Milk-V Mars to within 0.02%, and losing to a quad Cortex-A53 from 2012. On SHA-512, where nobody has hardware, it is only 5.9x behind a Cortex-A76. On AES-128-GCM it is 100x behind. That difference is the whole story - plus a hardware crypto engine sitting stranded behind missing userspace plumbing.
The worst benchmark number I ever published was an Orange Pi RV2 taking 650.60 seconds on a Rust compile that an RK3588 finishes in 52.55. I am now asking whether you would pay a monthly fee to rent RISC-V hardware from me. This is the arithmetic in public: what the SpacemiT K3 actually changed, why the one RISC-V box you can rent today implements a vector draft that was never ratified, what two nodes in a 1U at a Miami colo would really cost per month, and the strongest argument against the whole idea, which is a finding from my own build farm.
Building and deploying OpenBSD 7.9 on a Raspberry Pi 4B from an Apple Silicon Mac, with wired DHCP, SSH, and passwordless doas. Includes a generic flashable image download that accepts your own SSH public key before boot.
NetBSD booted on my Milk-V Mars, joined the network, and then overwrote its own kernel with pkgsrc file data under sustained write load. The evidence first pointed at a double allocation inside UVM. That diagnosis was wrong. A custom PGAUDIT kernel, a Mars-shaped QEMU target, 256 permanent canary pages, and a controlled cache-flush experiment in DDB eventually showed two physical addresses exactly 4 GiB apart reaching the same DDR backing. The unsafe 8 GiB map came from a blank EEPROM and U-Boot SPL's private memory default. This is the sequel to my original bring-up article: the wrong theories, the two device trees hiding in one boot chain, the one-line firmware correction, and the 600-second hardware A/B that contained the corruption.
My single-board computers hang, drop USB, and eat SD cards in ways my old Xeon server never does, and "you get what you pay for" is a shrug, not an explanation. So this is an attempt at the actual explanation: where the money goes in a server-class machine, why none of it shows up on a spec sheet, and why the same bit flip that increments a counter on the Xeon becomes an unwitnessed mystery hang on a NanoPi. Power delivery, SD card physics, tablet silicon versus mainframe silicon, Google's DRAM study, one Heidegger digression, and the parts of the missing margin you can buy back with a real power supply, a watchdog timer, and three idle boards' worth of Kubernetes.
