I tried to melt my Intel Ultra 7 router setup simulating 250 VR users for an off-grid festival app. Here's what happened. - Networking - Linus Tech Tips
Jump to content
I tried to melt my Intel Ultra 7 router setup simulating 250 VR users for an off-grid festival app. Here's what happened.
By
-J.
4 minutes ago in Networking
webrtc
p2p
networking
webxr
benchmark
intelcoreultra
Share
https://linustechtips.com/topic/1637924-i-tried-to-melt-my-intel-ultra-7-router-setup-simulating-250-vr-users-for-an-off-grid-festival-app-heres-what-happened/
More sharing options...
Followers
-J.
Member
Posted 4 minutes ago
Hey everyone,
I've been building an off-grid, zero-internet WebVR system designed to run on a festival floor. Because it relies on a peer-to-peer mesh structure, I knew the network traffic would scale exponentially.
Before packing up the gear for the actual deployment, I wanted to see exactly when my code would break my hardware. I ran a massive stress-test simulation pushing my local setup to a simulated 250 concurrent users (31,125 simultaneous data channels).
Here are the video recordings of my project handling the load, crashing the simulated router, and then dynamically sharding itself to heal the packet drops live.
The Test Bench Rig Specs<br>* Host Processor: Intel(R) Core(TM) Ultra 7 155H (16 Cores / 22 Threads)<br>* System Memory: 16 GB RAM Core Allocation (Has 64, not sure why it said this)<br>* Active Wireless NIC: Intel(R) Wi-Fi 6E AX211 160MHz #2<br>* Local Database Ledger: PostgreSQL Relational Memory Caching Matrix (Initialized Offline)
1. Internal Boot Sieve Timeline (Core Subsystems)<br>The backend engine initialized **34 out of 35 modules** cleanly in under a second.<br>The `platform_connections` module failed immediately due to an isolated cloud authentication check<br>(bypassed for pure offline local loopback execution).
The primary thread liftoff bottleneck remains `mesh_stream` as it primes local adapter socket interface layers:
• Submodule [mesh_stream] -> Time: 408.5 ms | Operational: True<br>• Submodule [postgres_db] -> Time: 165.2 ms | Operational: True<br>• Submodule [sim_harness] -> Time: 98.3 ms | Operational: True<br>• Submodule [video_processor] -> Time: 96.8 ms | Operational: Tr
2. Multi-Tier Full-Mesh Saturation Grid Results<br>Because this architecture operates as a pure peer-to-peer grid,<br>connection complexity scales exponentially according to the combination handshake formula.
Here are the raw performance metrics captured across three separate user tiers under peak load:
| NODES | STREAMS | PACKET LOSS | LATENCY | JITTER | THROUGHPUT | CONDITION |<br>| :--- | :--- | :--- | :--- | :--- | :--- | :--- |<br>| **64** | 2,016 | 151 | 7.47 ms | +-0.11 ms | 54.08 Mbps | OPTIMAL: Stable Mesh |<br>| **150** | 11,175 | 3,129 | 7.42 ms | +-0.28 ms | 558.39 Mbps | WARN: Buffer Choking |<br>| **250** | 31,125 | 14,940 | 7.56 ms | +-0.11 ms | 2.61 Gbps | CRITICAL: Router Dead |
3. Key Engineering Observations
The Processing Victory (7.50 ms Latency)<br>Raw hardware latency row. Whether managing 2,016 streams or an absolute flood of 31,125 streams,<br>the loop processing velocity remains locked around 7.50 ms.<br>This completely crushes the $15\text{ ms}$ human motion-sickness threshold.<br>Because the architecture offloads individual tracking and rendering math to the edge client devices,<br>the host laptop's CPU utilization sat flat at a cool 12%.
The Physical Airwave Wall (14,940 Dropped Packets)<br>While the compute layer handled the scale easily, the wireless airwaves hit a hard physical ceiling.<br>At 250 un-sharded users, the system attempted to push a massive 2.61 Gbps (bursting over 4.5 Gbps at peak saturation)<br>across the interface card. This completely choked the consumer router's internal RAM buffer,<br>resulting in 14,940 dropped packets. The processing code was ready, but the physical hardware choked.
Resolving the Bottleneck via Software Sharding<br>To keep this massive computing pool alive without melting the router, the software activates its strict<br>Dynamic Room Sharding constraints:<br>* The Sharding Rule: The code enforces a hard capacity limit of **16 peers per sub-room cluster ($n \le 16$).<br>* The Scale Transformation: When 250 users join the festival grid, the server automatically shards them into 16 isolated room<br>clusters.
Instead of a single chaotic room forcing 31,125 simultaneous streams over the air,<br>16 rooms of 16 users generate a total of just 1,920 streams across the entire venue.<br>Total sustained network traffic drops to a clean 576 Mbps, dropping hardware packet loss to a flat 0,<br>letting an off-the-shelf consumer router host a massive 250-user off-grid virtual grid seamlessly!
4. The Silicon Valley Evaluation: Middle-Out Metric<br>To evaluate this optimization against standard engineering baselines, I calculated the system's official<br>Weissman Score:
* Competing Tech Footprint: 2.11 Mbps per user (Raw Uncompressed H.264 Video tracking stream)<br>* My Mesh Network Footprint: 0.20 Mbps (200 Kbps) per user...