Device performance under OpenWrt
The same measurement across every ported device, so one board can be compared with another on identical firmware.
Two frame sizes are published here, 60 B and 1400 B, and both as bandwidth on the cable: megabits per second counted the way the wire carries them, each frame plus its checksum, preamble and inter-frame gap (L1). Measured the same way at both sizes, every wired bar reads against the same gigabit link, so a 60 B bar and a 1400 B bar can be compared directly. Whether a given bar is AT the link's capacity or far below it is what the bar itself says, and the caption claims nothing about which is which. WiFi figures have no cable framing and are counted at the frame itself (L2). Every size the suite measures, and every qualifier each figure was measured with, stays in the dated artifact these pages are generated from.
DHCP LAN->WAN, 60 B frames
DHCP WAN->LAN, 60 B frames
DHCP+VLAN LAN->WAN, 60 B frames
DHCP+VLAN WAN->LAN, 60 B frames
PPPoE CHAP LAN->WAN, 60 B frames
PPPoE CHAP WAN->LAN, 60 B frames
PPPoE CHAP+VLAN LAN->WAN, 60 B frames
PPPoE CHAP+VLAN WAN->LAN, 60 B frames
PPPoE PAP LAN->WAN, 60 B frames
PPPoE PAP WAN->LAN, 60 B frames
PPPoE PAP+VLAN LAN->WAN, 60 B frames
PPPoE PAP+VLAN WAN->LAN, 60 B frames
DHCP LAN->WAN, 1400 B frames
DHCP WAN->LAN, 1400 B frames
DHCP+VLAN LAN->WAN, 1400 B frames
DHCP+VLAN WAN->LAN, 1400 B frames
PPPoE CHAP LAN->WAN, 1400 B frames
PPPoE CHAP WAN->LAN, 1400 B frames
PPPoE CHAP+VLAN LAN->WAN, 1400 B frames
PPPoE CHAP+VLAN WAN->LAN, 1400 B frames
PPPoE PAP LAN->WAN, 1400 B frames
PPPoE PAP WAN->LAN, 1400 B frames
PPPoE PAP+VLAN LAN->WAN, 1400 B frames
PPPoE PAP+VLAN WAN->LAN, 1400 B frames
WiFi
Each device shows its highest valid measured OpenWrt throughput across WiFi bands for the same direction, WAN service and frame size. Each bar names its own operating point -- band, width, standard and cipher; the channel is recorded per measurement in the dated artifact, and is left off the bar because at one band, width, standard and cipher two channels negotiate the same thing -- beside its figure, because bars on one chart may have been taken at different points; where they differ, the gap between them includes that difference and no percentage is claimed. These are end-to-end figures over the device's own WAN, not an isolated radio measurement, and the client, the channel and the air are in them too. A device with no WiFi does not appear here at all.
WiFi -> WAN -- DHCP, 60 B frames
WiFi -> WAN -- DHCP+VLAN, 60 B frames
WiFi -> WAN -- PPPoE CHAP, 60 B frames
WiFi -> WAN -- PPPoE CHAP+VLAN, 60 B frames
WiFi -> WAN -- PPPoE PAP, 60 B frames
WiFi -> WAN -- PPPoE PAP+VLAN, 60 B frames
WAN -> WiFi -- DHCP, 60 B frames
WAN -> WiFi -- DHCP+VLAN, 60 B frames
WAN -> WiFi -- PPPoE CHAP, 60 B frames
WAN -> WiFi -- PPPoE CHAP+VLAN, 60 B frames
WAN -> WiFi -- PPPoE PAP, 60 B frames
WAN -> WiFi -- PPPoE PAP+VLAN, 60 B frames
WiFi -> WAN -- DHCP, 1400 B frames
WiFi -> WAN -- DHCP+VLAN, 1400 B frames
WiFi -> WAN -- PPPoE CHAP, 1400 B frames
WiFi -> WAN -- PPPoE CHAP+VLAN, 1400 B frames
WiFi -> WAN -- PPPoE PAP, 1400 B frames
WiFi -> WAN -- PPPoE PAP+VLAN, 1400 B frames
WAN -> WiFi -- DHCP, 1400 B frames
WAN -> WiFi -- DHCP+VLAN, 1400 B frames
WAN -> WiFi -- PPPoE CHAP, 1400 B frames
WAN -> WiFi -- PPPoE CHAP+VLAN, 1400 B frames
WAN -> WiFi -- PPPoE PAP, 1400 B frames
WAN -> WiFi -- PPPoE PAP+VLAN, 1400 B frames
WiFi -> WAN -- TCP max
WAN -> WiFi -- TCP max
WiFi latency
Round-trip delay over the air, at the 95th percentile -- the tail a user actually notices, not the average. Lower is better on these charts, the opposite of every chart above, so the bars are drawn in a different colour and each states the direction. Each bar names its own operating point. The idle chart is the floor; the loaded ones show what happens to it while another device is using the same radio, which is the case a shared medium makes worst.
WiFi -> WAN, idle
WiFi -> WAN, a second device loading the WAN over the cable (downstream)
WiFi -> WAN, the same station loading its own link (downstream)
WiFi -> WAN, a SECOND WiFi device loading the air (upstream)
WiFi -> WAN, a SECOND WiFi device loading the air (downstream)
4 WiFi latency point(s) on G24W, X400AXF carry no figure that can be placed beside another device's: measured, but the producer recorded no figure at this point; the cell CONTRADICTS ITSELF as a device figure: it records limited_by=host, and the lab host is the INSTRUMENT -- a many-core desktop measuring a sub-gigabit CPE. The producer's own verdict is that the repair is the generator, so this number describes the bench and would be read as the device's. It stays in the dated artifact with every field it was measured with.; the point is BLOCKED on this device -- nothing was measured, so there is no figure to place on an axis
WiFi stability
Lower is better for loss and delay; higher is better for the download and upload rates.
Round trips from the first WiFi client to the WAN-side lab target. Idle download and upload are that client's own maximum TCP rate on the same band and cipher. Under load, a second client on the same AP downloads or uploads, or the first client itself downloads; the rate that load achieved is shown beside the round trips measured under it. Loss is packet loss; p95 is delay in milliseconds. A dash means that metric is unavailable; n/a marks the direction a load row does not run.
Idle
| Device | Band | Download | Upload | Loss | p95 |
|---|---|---|---|---|---|
| G24W | 2.4 GHz | 31.1 Mbps | 56.9 Mbps | 7.10% | 4.02 ms |
| V2801RGW | 2.4 GHz | 33.7 Mbps | 49.8 Mbps | 0.00% | 31.3 ms |
| X111W | 2.4 GHz | 77.7 Mbps | 93.8 Mbps | 0.00% | 11.6 ms |
| X400AXF | 5 GHz | 181 Mbps | 160 Mbps | 0.00% | 38.2 ms |
Another client downloading or uploading
| Device | Band | Download | Upload | Loss | p95 |
|---|---|---|---|---|---|
| G24W | 2.4 GHz | 0.6 Mbps | n/a | 63.4% | 1194 ms |
| G24W | 2.4 GHz | — | Not captured | — | — |
| V2801RGW | 2.4 GHz | 28.6 Mbps | n/a | 0.00% | 166 ms |
| V2801RGW | 2.4 GHz | n/a | 26.8 Mbps | 0.1% | 61.6 ms |
| X111W | 2.4 GHz | 27.6 Mbps | n/a | 0.00% | 96.3 ms |
| X111W | 2.4 GHz | n/a | 54.7 Mbps | 0.00% | 108 ms |
| X400AXF | 5 GHz | 217 Mbps | n/a | 0.00% | 281 ms |
| X400AXF | 5 GHz | n/a | 225 Mbps | 0.2% | 640 ms |
The client itself downloading
| Device | Band | Download | Upload | Loss | p95 |
|---|---|---|---|---|---|
| G24W | 2.4 GHz | Not captured | — | — | — |
| V2801RGW | 2.4 GHz | 32.5 Mbps | n/a | 0.00% | 102 ms |
| X111W | 2.4 GHz | 25.8 Mbps | n/a | 0.00% | 40.1 ms |
| X400AXF | 5 GHz | Not captured | — | — | — |
GPON protocol processing
Microseconds each device's own CPU spends per PLOAM and OMCI message: a real OLT's activation and provisioning, frozen, replayed with no OLT, the same bytes on every device -- so the figures compare across devices and do not move when the OLT changes. Lower is better. The chart is the OMCI median; for scale, an OLT asks about one OMCI message every 20 000 us.
| Device | PLOAM p50 | PLOAM p95 | OMCI p50 | OMCI p95 |
|---|---|---|---|---|
| G24W | 2.6 us | 2.9 us | 9.0 us | 14.7 us |
| V2801RGW | 8.0 us | 8.0 us | 17.3 us | 25.9 us |
| X100DG | 16.0 us | 16.3 us | 35.8 us | 53.8 us |
| X111W | 7.7 us | 8.0 us | 17.3 us | 25.9 us |
| X400AXF | 0.2 us | 0.2 us | 3.0 us | 5.4 us |
Device resources
One static program on each device's own CPU: the CPUs online, the memory the kernel manages, a table-driven CRC-32 on one core (the byte-wise code a protocol stack runs), memcpy across buffers larger than the caches (at most a quarter of the free memory, so the 32 MB devices run it too), and the lab host streaming into the device over ssh (cipher and CPU together). Higher is better.
CPUs online
Memory the kernel manages (MemTotal)
CPU: table-driven CRC-32 on one core
Memory: memcpy past the caches
Management link: ssh pipe into the device
CPU core and compiler fixes
| Device | CPU core | ISA | Core-specific compiler flags |
|---|---|---|---|
| G24W | Realtek Luna - MIPS interAptiv core (RTL9607C, RTL9603CVD) | mips_24kc | none |
| V2801RGW | Realtek Luna - RLX Taroko core (RTL9602C, RTL9603C) | mips_mips32 | -mno-branch-likely -mips32 -mtune=mips32 -fno-schedule-insns2 -mfix-rlx |
| X100DG | Realtek Luna - RLX Taroko core (RTL9602C, RTL9603C) | mips_mips32 | -mno-branch-likely -mips32 -mtune=mips32 -fno-schedule-insns2 -mfix-rlx |
| X111W | Realtek Luna - RLX Taroko core (RTL9602C, RTL9603C) | mips_mips32 | -mno-branch-likely -mips32 -mtune=mips32 -fno-schedule-insns2 -mfix-rlx |
| X400AXF | Realtek RTL9607F Cortex-A55 | aarch64_generic | none |
-fno-schedule-insns2: Lexra MDU erratum: a load in the mult/div result shadow corrupts HI/LO-mfix-rlx: an RLX branch whose delay slot is a three-operand mul decides on the mul result-mips32: MIPS32 R1: the RLX/Lexra encodings its C library needs
Among the WiFi points published here, 48 further WiFi point(s) on G24W, V2801RGW, X111W, X400AXF carry no figure that can be placed beside another device's: the point is BLOCKED on this device -- nothing was measured, so there is no figure to place on an axis
WiFi signal: ONU -> client
Signal the lab WiFi client receives from each ONU under OpenWrt, the strongest reading per device and band. Higher is better: -15 dBm is a stronger signal than -24 dBm. dBm is already a logarithmic unit (every 3 dB doubles the power), so each bar is the dB the signal stands above -100 dBm, about the noise floor of a 20 MHz channel: a longer bar is a stronger signal. The antennas sit within 1 m of the ONUs: this is not a range figure.
2.4 GHz
5 GHz
these devices were not heard by the same instrument in the same state (2 different receiving radios; client transmit powers that were not the same; at least one reading whose client power was not recorded, which is not the same as matching), so the figures are printed but NOT compared: a received level is the emission minus the path and the receiver, so the difference between two such columns could be the instrument's rather than the devices'.
The receiving client or its settings were not recorded for some readings; a controlled comparison is not established.