Hi everyone,

We operate a VR arcade that uses Wi-Fi streaming to deliver high-quality PC VR experiences without cables. Thanks to recent advances in headset hardware and software, it's finally viable to stream demanding PC VR games over Wi-Fi with solid visual quality.

However, streaming VR at scale has strict bandwidth and stability requirements. Each PC-to-headset stream needs consistent throughput, often between 30 Mbps (acceptable) and 150–200 Mbps (maximum visual quality).

We're planning to run a venue with 24 headsets, of which 16 will stream over Wi-Fi from dedicated PCs. Today, we ran our first test using TP-Link equipment, with help from their team. Here's what we learned:
 

Test Setup

• Gateway: TP-Link Omada ER7412-M2 V1.20

• Access Point (AP): TP-Link Omada EAP783

• Connection:

  • PC → 2.5G/10G Ethernet → Gateway

  • Gateway → 10G Ethernet → Access Point

  • Access Point → Wi-Fi 7 → Headsets (Pico 4 Ultra Enterprise)

• Number of PCs tested: 4
  
  We tested multiple configurations — channel width, band settings, QoS tweaks, and client isolation — but no matter the setup, we couldn’t push beyond the 300 Mbps stable throughput mark. We could spike up to ~450 Mbps in short bursts, but anything beyond 300 Mbps quickly became unstable and unusable for VR streaming (packet loss, jitter, dropped frames).

  So while the EAP783 handles general high-throughput traffic well, it seems to hit a ceiling when handling multiple constant low-latency VR streams — even with only 4 headsets connected.

• 

• 

• 

Results

No matter which Wi-Fi or streaming settings we used, the EAP783 consistently capped out at around 300 Mbps of stable throughput across all devices. That means:

• Streaming worked perfectly as long as total traffic stayed under 300 Mbps.

• But once we tried to push beyond that (e.g., 4 PCs at 150 Mbps or 80 Mbps each), packet loss occurred on the Wi-Fi side, causing performance drops in the VR experience.

• The wired (PC → AP) connection showed no issues—so the bottleneck is clearly on the wireless transmission from AP to headset.

Conclusion

While the test setup showed promise, it also highlighted a hard throughput ceiling on the current AP. For our 16-headset setup to work smoothly with high visual fidelity, we’ll need either higher-capacity APs or a distributed network setup with multiple APs to handle the load.

From talking to other VR arcades with similar setups, this 300 Mbps cap seems common. Most venues report they can't run more than 2 headsets per AP/router reliably. In that sense, hitting stable performance with 4 headsets per AP puts us slightly ahead — but the limit is still there.

That raises concerns for our full setup. If we're aiming for 16 headsets in the same space, we’ll need to manage channel overlap, which gets tricky fast. For reference, another venue is using 6 Wi-Fi 7 APs to run just 14 headsets, and they can only keep streams stable at around 30 Mbps per headset.

I'm not a networking or hardware expert, but it seems likely we're hitting either a chipset-level bottleneck in packet handling or we’re just facing a scenario that current APs aren’t built to handle — especially with the ultra-low latency and high stability VR streaming demands.

To be clear: the AP can burst above 300 Mbps (we peaked at ~450), but anything beyond 300 becomes unstable for VR. For general use, it's fine. But for wireless VR streaming, that instability kills the experience.

This isn’t just a one-off issue. There’s a growing community of arcades worldwide (15.000+ EU/NA), and many of us are hitting the same wall: Wi-Fi streaming for VR is consistently limited by access point stability, not raw bandwidth or device specs. I'd really appreciate it if TP-Link — could take a closer look at this use case. Wireless VR streaming has specific, high-demand requirements that current hardware doesn’t seem fully optimized for. Even some insights into chipset behavior or firmware tuning would be valuable.

If anyone has achieved better stability at higher throughput, or knows of APs designed with ultra-low latency, high-packet-rate environments in mind, I’d love to hear your setup.