I've been evaluating the long-term viability of several older Celeron J1900 appliances as backup routers in a lab environment. The goal is to determine if these units, which are now quite dated, can still achieve a full gigabit wire-speed routing baseline under both pfSense 2.7+ and OPNsense 24.x with modern feature sets enabled. The specific hardware is a Protectli Vault 4-port unit with 8GB RAM and an SSD.
My preliminary testing revealed a significant performance delta between the two forks that seems rooted in driver implementation and default tuning. I am seeking to corroborate or challenge these findings with others who have conducted similar controlled benchmarks.
**Test Methodology & Baseline:**
* **Test Tool:** iperf3, bidirectional TCP streams.
* **Traffic Profile:** 1500 byte MTU, purely routed (no NAT), between two VLANs on separate interfaces.
* **Features Enabled:** Basic stateful firewall with a minimal rule set, no DNS/IDP/DPI packages loaded.
* **Kernel Tuning:** Tested with both default settings and with `net.isr.dispatch=deferred` (pfSense) and equivalent net.isr tunables in OPNsense.
**Initial Results Summary:**
| Metric | pfSense 2.7.2 (Default) | OPNsense 24.1.7 (Default) | Notes |
| :--- | :--- | :--- | :--- |
| **Max Routing Throughput** | ~942 Mbps | ~650 Mbps | Single iperf3 stream, 20-second test. |
| **CPU Utilization** | 75-85% (all cores) | 95-100% (core 0 pinned) | Observed via `top -P`. |
| **Driver Identified** | `em` | `lem` | FreeBSD driver for Intel I211AT chips. |
The performance bottleneck on OPNsense appears correlated with the `lem` driver's apparent inability to distribute interrupts across all four CPU cores effectively on the J1900, leading to a single-core saturation. Forcing the `em` driver in OPNsense via loader.conf (`hw.em.loader="YES"`) improved throughput to approximately 890 Mbps, but introduced periodic latency spikes.
**Key Questions for the Community:**
1. Has anyone else performed an apples-to-apples routing throughput test on this generation of CPU (Bay Trail J1900/J1800) with both firewalls?
2. Are there specific system tunables (beyond the generic net.isr ones) you've found critical for achieving wire-speed on this low-power, quad-core architecture with OPNsense's default driver stack?
3. Has the performance gap persisted in your testing with more recent releases (e.g., OPNsense 24.7)?
I will follow up with the full test configuration, including the exact `sysctl` values and the iperf3 command syntax, once I have compiled the final dataset. The implication for lab and edge deployments is non-trivial; a 300 Mbps deficit under simple routing could mean the hardware is unsuitable for any VPN or filtering workload on a gigabit line.
--DC
data is the product
Interesting. I ran a similar test on a Qotom J1900 box a while back, but for a small business edge use-case with NAT enabled. The performance drop-off was... significant, shall we say, compared to your routed test.
>significant performance delta between the two forks
That's the key bit. I found the same, mostly down to the Realtek driver handling. In my case, OPNsense with the `realtek-re` plugin consistently edged out pfSense's built-in realtek driver for throughput, especially with any packet inspection active. Curious which one came out ahead in your results?