You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Spike under EPIC #254. Question: can a warehouse-scale fleet of cell (gNB-DU) nodes run on ARM SBCs instead of x86 mini-PCs — cheaper, lower-power, and (the real deployment lever) PoE-powered — without giving up the timing tiers the epic depends on?
Context: the proven cell-node stack is x86 (Intel N100-class) + Intel I226 HW-PTP (~290 ns RMS vs Wi-Fi TSF) + RTL8821CE over PCIe/vfio (~12 µs submit-to-air; AP↔PTP hold ~0.67 µs via PinBeaconTbtt). devourer's ARM64 USB path is proven daily; the PCIe transport is x86-validated only. The dev rig purchase (3× J6412 boxes) proceeds regardless — this spike only decides the scale-out tier.
Three gates an ARM cell node must pass
vfio/IOMMU — PcieTransport rides vfio-pci, which needs an IOMMU. Most cheap ARM SoCs wire no SMMU in front of PCIe (RK3588, i.MX8M). vfio-noiommu exists but has no DMA mapping API, so our DMA rings would need a physical-address/hugepage scheme — engineering work, not a config flag.
PTP quality of the SoC MAC — "ethtool -T shows the bits" ≠ I226-grade. Needs a measured offset distribution per candidate.
USB-tier fallback semantics — an ARM node driving the radio over USB is supported today, but that is the coarse-sync tier (~93 µs transport jitter). PinBeaconTbtt discipline quality over USB is unmeasured; its number decides whether warehouse cells need PCIe at all.
Measurement plan (zero-purchase: Orange Pi 5 Plus on hand answers most of it)
A — PTP bench on RK3588 2.5GbE: ethtool -T, then ptp4l slave against an i226 master; report offset RMS + tail vs the I226↔I226 baseline.
B — 8821CE in the RK3588 M.2 E-key slot: does it enumerate; does vfio (noiommu) bind; how far does pcieprobe get. Expected to stop at DMA mapping — document exactly where, and scope the noiommu DMA-ring work if it's the only blocker.
C — PinBeaconTbtt-over-USB discipline (any host, any generation with beacon support): close the AP↔PTP loop with the radio on USB instead of PCIe; report the hold distribution. This is the highest-value number: if it lands ~10 µs, USB-tier ARM cells are legitimate for everything except tight same-channel slot coordination.
D — paper pass on candidates (only if A–C are promising): RPi5/CM5 (PCIe FPC → E-key, PoE+ HAT, IOMMU status unknown), i.MX8M Plus (TSN-grade PTP, industrial), and the explicit rejects — Realtek-NIC boards (r8169 PTP patchy), MediaTek hosts (16 KB bulk-IN cap, see README/CLAUDE.md).
Exit criteria
Either: a named ARM board + attach mode (PCIe or USB) with measured PTP offset and beacon-discipline numbers fit for a stated tier of the epic (tight vs coarse), plus a costed BOM per node — or: a documented "x86 stays the cell-node platform because gate N fails and closing it costs more than the fleet savings."
Non-goal: porting PcieTransport to noiommu DMA inside this spike — scope it, don't build it.
Spike under EPIC #254. Question: can a warehouse-scale fleet of cell (gNB-DU) nodes run on ARM SBCs instead of x86 mini-PCs — cheaper, lower-power, and (the real deployment lever) PoE-powered — without giving up the timing tiers the epic depends on?
Context: the proven cell-node stack is x86 (Intel N100-class) + Intel I226 HW-PTP (~290 ns RMS vs Wi-Fi TSF) + RTL8821CE over PCIe/vfio (~12 µs submit-to-air; AP↔PTP hold ~0.67 µs via
PinBeaconTbtt). devourer's ARM64 USB path is proven daily; the PCIe transport is x86-validated only. The dev rig purchase (3× J6412 boxes) proceeds regardless — this spike only decides the scale-out tier.Three gates an ARM cell node must pass
PcieTransportrides vfio-pci, which needs an IOMMU. Most cheap ARM SoCs wire no SMMU in front of PCIe (RK3588, i.MX8M).vfio-noiommuexists but has no DMA mapping API, so our DMA rings would need a physical-address/hugepage scheme — engineering work, not a config flag.ethtool -Tshows the bits" ≠ I226-grade. Needs a measured offset distribution per candidate.PinBeaconTbttdiscipline quality over USB is unmeasured; its number decides whether warehouse cells need PCIe at all.Measurement plan (zero-purchase: Orange Pi 5 Plus on hand answers most of it)
ethtool -T, thenptp4lslave against an i226 master; report offset RMS + tail vs the I226↔I226 baseline.pcieprobeget. Expected to stop at DMA mapping — document exactly where, and scope the noiommu DMA-ring work if it's the only blocker.PinBeaconTbtt-over-USB discipline (any host, any generation with beacon support): close the AP↔PTP loop with the radio on USB instead of PCIe; report the hold distribution. This is the highest-value number: if it lands ~10 µs, USB-tier ARM cells are legitimate for everything except tight same-channel slot coordination.Exit criteria
Either: a named ARM board + attach mode (PCIe or USB) with measured PTP offset and beacon-discipline numbers fit for a stated tier of the epic (tight vs coarse), plus a costed BOM per node — or: a documented "x86 stays the cell-node platform because gate N fails and closing it costs more than the fleet savings."
Non-goal: porting
PcieTransportto noiommu DMA inside this spike — scope it, don't build it.