EnGenius ECW536 Wi‑Fi 7 Access Point; Real-World Performance Review
Test date: May 25, 2026; Follow-up June 18 2026 (Firmware Update)
Client hardware: Intel BE211 2×2 802.11be adapter (PCIe)
Client driver: iwlwifi, Linux kernel 7.0.1
Test environment: RF-shielded chamber (foil-lined room, ~3 m client-to-AP distance, line of sight, Steve’s Old Sound Chamber
What we tested
The EnGenius ECW536 is a tri-band Wi‑Fi 7 access point supporting 2.4 GHz, 5 GHz, and 6 GHz radios with Multi-Link Operation (MLO). We evaluated it alongside an ASUS BE-18000 and a NETGEAR Nighthawk RS700S as comparison baselines. All APs were tested with the same Intel BE200 client in a controlled RF environment that eliminates external interference.
All throughput tests used iperf3 (10-second duration), with concurrent ping at 10 ms intervals for latency-under-load measurement. Load sweeps used UDP with stepped offered loads and 3-second warm-up per step.
EnGenius ECW536 / Throughput Results
The EnGenius was tested in two configurations:
- MLO mode (default): Both 5 GHz and 6 GHz links active simultaneously
- Single-link 6 GHz: Connected via 6 GHz only (320 MHz channel width)
| Test | Direction | Streams | MLO (5G+6G) | 6 GHz only |
|---|---|---|---|---|
| TCP | client → server | 1 | 1,389 Mbps | 2,307 Mbps |
| TCP | client → server | 2 | 3,161 Mbps | 3,071 Mbps |
| TCP | server → client | 1 | 2,488 Mbps | 2,534 Mbps |
| TCP | server → client | 2 | 3,026 Mbps | 3,030 Mbps |
| UDP | client → server | 1 | 807 Mbps | 820 Mbps |
| UDP | client → server | 2 | 1,184 Mbps | 1,208 Mbps |
3+ Gbps TCP in both directions the EnGenius exceeds the ~2.4 Gbps single-link theoretical maximum when MLO is active, confirming both 5 GHz and 6 GHz links are carrying traffic simultaneously. Throughput is fully symmetrical in both forward and reverse directions. This is a big deal to me because “Wifi7” has been a crapshoot in our testing.
Three-Way Comparison
| Metric | EnGenius ECW536 (MLO) | NETGEAR RS700S (6 GHz) | ASUS BE-18000 (6 GHz) |
|---|---|---|---|
| TCP 2x forward | 3,161 Mbps | 2,892 Mbps | 2,195 Mbps |
| TCP 2x reverse | 3,026 Mbps | 3,512 Mbps | 389 Mbps |
| UDP 2x forward | 1,184 Mbps | 1,297 Mbps | 1,301 Mbps |
| Idle p99 latency | 6.7 ms | 12.6 ms | 7.0 ms |
| Worst load p99 | 28.9 ms | 28.3 ms | 19.1 ms |
| p99 delta | 22.2 ms | 15.7 ms | 12.1 ms |
| Reverse symmetry |  Yes |
Yes |
 No (6:1 ratio) |
| MLO support | EMLSR, 2 links | None detected | MLD capable only |
The ASUS reverse asymmetry
The most striking difference between the three APs is the ASUS’s severe TCP reverse (server→client) throughput limitation. At ~350–390 Mbps reverse vs ~2,200 Mbps forward, the ASUS exhibits a roughly 6:1 asymmetry. This was reproducible across multiple test sessions and across both 5 GHz and 6 GHz bands. Both the EnGenius and NETGEAR are fully symmetrical at over 3 Gbps in both directions.
This suggests an AP-level issue in the ASUS. I would hazard a guess to say it is likely in the downlink scheduler, TX queue management, or aggregation strategy when handling server-to-client TCP traffic.
How’s the wireless for latency for gamers?
This has come up on the forum fairly regularly. Wired is, of course, always better.
On a wired Ethernet connection, you’re used to seeing ping times of 1 ms or less to your router. The entire round trip from your PC to the router and back takes about 0.3–0.5 ms on a typical home network.
Wi‑Fi replaces that dedicated wire with a shared radio channel. Even on a perfectly clean link, every packet has to wait for a clear channel, be transmitted with forward error correction, be acknowledged by the receiver, and potentially be retransmitted if the ACK doesn’t arrive. The Wi‑Fi MAC layer adds about 1–2 ms of fixed overhead per round trip just for this channel access and acknowledgment dance. Then there’s the over-the-air propagation time (negligible at 3 m), and any queuing in the AP’s processor.
What does this mean in practice for a gamer? Here are the idle p50 latencies we measured across all three APs on a completely unloaded link:
| AP | Idle p50 | Idle p99 | Notes |
|---|---|---|---|
| EnGenius ECW536 (MLO) | 2.7 ms | 6.7 ms | Best idle latency |
| ASUS BE-18000 (6 GHz) | 3.5 ms | 7.0 ms | |
| NETGEAR RS700S (6 GHz) | 4.5 ms | 12.6 ms | Different ping target |
| Wired reference | ~0.5 ms | ~1 ms | Typical wired router ping |
The p50 values of 2.7–4.5 ms are what you’d actually feel in a game — that’s the typical ping you’d see to your first hop. Compared to wired’s ~0.5 ms, wireless adds about 2–4 ms of baseline latency. For context:
- A single frame at 60 FPS is 16.7 ms
- A single frame at 144 FPS is 6.9 ms
- The difference between 2.7 ms and 0.5 ms is 2.2 ms (less than half a frame at 144 Hz)
For MMOs and MOBAs, which are typically not bandwidth-hungry (a League of Legends or WoW session uses roughly 0.1–1 Mbps), you’ll be operating in the lightest-load regime we tested. Under those conditions (say, the 100 Mbps UDP load sweep step) all three APs delivered p50 latency between 3.5 and 4.5 ms and p99 between 7 and 11 ms. That’s well within what any competitive gamer would consider playable.
The more important concern for gamers isn’t the absolute latency, I think, it’s probably latency consistency. From own experience gaming I am more likely to notice a latency spike from 10 to 100ms on a fiber optic connection, for example, than I am a connection that is a consistent 100ms.
On this front, all three APs performed well in our tests, with the ASUS showing the best jitter control (tightest p95-to-p99 spread) and the EnGenius MLO showing the lowest absolute idle latency.
The bottom line: if you’re coming from wired, you’ll add about 2–4 ms of ping to your first hop by switching to Wi‑Fi 7. For any modern online game, that difference should be imperceptible.
The much bigger variable is your internet connection’s latency to the game server, which is typically 20–80 ms and dwarfs the local wireless overhead.
If your wifi spectrum is congested, then technologies for fast frequency hopping to try to “delete” the latency spike before it happens are much more critical. imho.
Latency Under Load
Latency was measured with concurrent ping at 10 ms intervals during each throughput test. The key metric I wanted to test here was the p99 delta.
I’m trying to nail down what happens with p99 latency and p99 under load, which indicates bufferbloat severity (thanks, Dave).
| Test | EnGenius MLO p99 | EnGenius 6G p99 | ASUS 6G p99 |
|---|---|---|---|
| Idle baseline | 6.7 ms | 12.2 ms | 7.0 ms |
| TCP 1x forward | 22.8 ms (+16.1) | 70.9 ms (+58.7) | 17.8 ms (+10.8) |
| TCP 2x forward | 23.2 ms (+16.6) | 21.9 ms (+9.7) | 19.1 ms (+12.1) |
| TCP 1x reverse | 19.4 ms (+12.8) | 21.0 ms (+8.8) | 8.2 ms (+1.2) |
| TCP 2x reverse | 28.9 ms (+22.2) | 29.5 ms (+17.3) | 9.9 ms (+2.9) |
| UDP 2x forward | 17.1 ms (+10.5) | 20.5 ms (+8.3) | 10.6 ms (+3.6) |
The EnGenius in MLO mode shows better idle latency (6.7 ms) than single-link 6 GHz (12.2 ms), likely because the MLO connection distributes management and data across two links. However, the ASUS has lower p99 deltas under load. I do not believe its queue management is tuned well. It is more aggressive at keeping latency down, even though its reverse throughput is crippled. Someone probably missed a decimal point.
Load Sweep – Latency vs Offered Load
UDP load sweeps show how latency behaves as offered load increases. The EnGenius was tested in forward and reverse directions.
EnGenius Forward (UDP, 2 streams)
| Offered | Achieved | p99 Latency |
|---|---|---|
| 100 Mbps | 100 Mbps | 10.1 ms |
| 250 Mbps | 250 Mbps | 9.6 ms |
| 500 Mbps | 500 Mbps | 10.2 ms |
| 750 Mbps | 750 Mbps | 16.3 ms |
| 1,000 Mbps | 1,000 Mbps | 14.1 ms |
| 1,500 Mbps | 1,186 Mbps | 91.9 ms |
| 2,000 Mbps | 1,184 Mbps | 11.4 ms |
| 2,500 Mbps | 1,239 Mbps | 10.3 ms |
EnGenius Reverse (UDP, 2 streams)
| Offered | Achieved | p99 Latency |
|---|---|---|
| 100 Mbps | 100 Mbps | 90.7 ms |
| 250 Mbps | 248 Mbps | 7.5 ms |
| 500 Mbps | 496 Mbps | 13.6 ms |
| 750 Mbps | 743 Mbps | 7.1 ms |
| 1,000 Mbps | 928 Mbps | 8.4 ms |
| 1,500 Mbps | 1,413 Mbps | 16.1 ms |
| 2,000 Mbps | 1,759 Mbps | 25.2 ms |
| 2,500 Mbps | 1,960 Mbps | 37.1 ms |
ASUS Forward (UDP, 2 streams)
| Offered | Achieved | p99 Latency |
|---|---|---|
| 100 Mbps | 100 Mbps | 11.1 ms |
| 250 Mbps | 250 Mbps | 13.8 ms |
| 500 Mbps | 500 Mbps | 17.2 ms |
| 750 Mbps | 750 Mbps | 13.7 ms |
| 1,000 Mbps | 1,000 Mbps | 11.5 ms |
| 1,500 Mbps | 1,312 Mbps | 8.3 ms |
| 2,000 Mbps | 1,306 Mbps | 8.8 ms |
| 2,500 Mbps | 1,316 Mbps | 8.7 ms |
Notable: The EnGenius forward sweep shows a latency spike at 1,500 Mbps (p99 = 91.9 ms) that disappears at higher loads. This is reproducible and appears to be a real scheduler behavior. I was not sure what to make of it.
The behavior here was more pronounced in the earlier firmware which suggests Engenius is aware of it. Possibly the AP transitioning between single-link and multi-link modes at that load threshold?
The ASUS forward sweep shows the opposite trend: latency decreases as load increases, suggesting its queue management behaves differently under sustained traffic.
Deep MLO Decode
We used tshark in monitor mode to capture and decode 802.11be Multi-Link Operation fields from beacon frames.
| Field | EnGenius ECW536 | ASUS BE-18000 | NETGEAR RS700S |
|---|---|---|---|
| MLD MAC address | Present | Present | Not found |
| EML capabilities present | Yes | No | No |
| EMLMR support | No | N/A | N/A |
| EMLSR support | Yes | N/A | N/A |
| SRS support | No | No | No |
| Max simultaneous links | 2 | Unknown | N/A |
| Recommended max links | 2 | Unknown | N/A |
The EnGenius advertises EMLSR (Enhanced Multi-Link Single-Radio) support with a maximum of 2 simultaneous links.
This is a huge deal because remember – Optional Wifi 7 features are where marketing goes to party.
Our testing confirmed both links were active during MLO operation.
The ASUS beacon does not populate EML subfields on the captured link, though it does advertise MLD capability. The NETGEAR beacon showed no MLO advertisement throughout our testing.
5 GHz Performance (ASUS only)
We also tested the ASUS on 5 GHz (80 MHz channel width) for reference:
| Test | Throughput | p99 delta |
|---|---|---|
| TCP 2x forward | 1,111 Mbps | 51.2 ms |
| TCP 2x reverse | 283 Mbps | 7.2 ms |
| UDP 2x forward | 760 Mbps | 18.1 ms |
The 80 MHz channel width on 5 GHz is a significant bottleneck compared to 320 MHz on 6 GHz, and bufferbloat is substantially worse (p99 delta of 51 ms on TCP multi-stream forward).
We tried to use this approach with the ECW to pin down bufferbloat related behaviors, but the device will simply drop packets when congested. (We think this is the right behavior – and a better behavior for gamers that probably want lowest latency-under-load.)
Test Methodology Notes
- RF environment: All testing was conducted in a foil-lined RF-shielded chamber or Steve’s chamber (originally built as a sound chamber, repurposed for RF isolation). External Wi‑Fi signals are attenuated to negligible levels.
- Client: Intel BE211 2×2, connected via
wlan0with iwlwifi driver on Linux kernel 7.0.1. (We also tested mediatek but that data just adds noise to this review and it doesn’t behave as consistently as intel.) - iperf3 server: Wired host on the AP’s LAN, connected via Gigabit Ethernet.
- Band selection: The client connected to the AP’s strongest available band by default. The EnGenius established MLO with both 5 GHz and 6 GHz links automatically. Isolating individual bands on the EnGenius would require disabling radios on the AP side.
- Load sweeps: UDP mode with
iperf3 -bfor precise offered-load control. Each step includes a 3-second warm-up and a 2-second inter-step gap for queue drain. - Latency measurement: Concurrent
pingat 10 ms intervals during all throughput tests. Percentiles computed from raw per-packet RTT samples. - NETGEAR latency note: The NETGEAR’s gateway does not respond to ICMP, so the iperf3 server was used as the ping target instead. This means absolute latency values for the NETGEAR are not directly comparable to the other APs, which used the gateway as the ping target.
Summary
| Category | EnGenius ECW536 | NETGEAR RS700S | ASUS BE-18000 |
|---|---|---|---|
| Peak TCP throughput | 3,161 Mbps | 3,512 Mbps | 2,195 Mbps |
| Reverse symmetry | Yes |
Yes |
No (6:1) |
| MLO support | EMLSR, 2 links active | None | MLD capable, no EML fields |
| Bufferbloat (worst p99 Δ) | 22.2 ms | 15.7 ms | 12.1 ms |
| UDP peak | 1,208 Mbps | 1,297 Mbps | 1,301 Mbps |
| Idle latency (p99) | 6.7 ms | 12.6 ms | 7.0 ms |
Bottom Line: The EnGenius ECW536 delivers excellent Wi‑Fi 7 performance with genuine Multi-Link Operation, exceeding 3 Gbps in both directions from a single client.
It is the only AP of the three tested that actively uses MLO with two simultaneous links.
Its main trade-off is higher bufferbloat under certain load patterns compared to the ASUS.
The NETGEAR RS700S wins on raw reverse throughput (3.5 Gbps) without MLO, while the ASUS BE-18000 has competitive forward throughput and the best latency management but its severe reverse-direction asymmetry (~350 Mbps) is a significant limitation for any workload with symmetrical traffic patterns.
