PCVR Streaming with GL.iNet Routers: A Call for Community Insights and Mega Thread Creation

I have embarked on an exploration journey to unlock the potential of GL.iNet routers in the context of PCVR (PC Virtual Reality) streaming, especially while on the move. I’ve acquired two of their products, the Beryl AX (GL-MT3000) and the Opal (GL-SFT1200), and have stumbled upon some intriguing findings through my tests. Despite the Opal being a less robust model with AC connectivity at 866Mbit/s and a modest processor, it surprisingly outperformed the more capable Beryl AX with AX connectivity at 1200Mbit/s in delivering a smoother PCVR experience.

The primary intent behind this endeavor is to create a highly portable PCVR setup while traveling, utilizing a notebook and a GL.iNet router. A crucial aspect of this setup is the direct Ethernet connection from the notebook to the router’s LAN port, ensuring a stable, low-latency link crucial for PCVR streaming. Additionally, the router is powered directly from the notebook’s USB port, which, in my opinion, meets the router’s power requirements effectively, forming an excellent mobile setup for engaging in PCVR.

As a bonus, the setup also allows for tethering a mobile phone via USB to the router, enabling internet access in any setting, which is a fantastic feature for on-the-go connectivity.

I am extending an invitation to our vibrant community, particularly the adept developers at GL.iNet, to contribute to a “Mega Thread”. The aspiration is to amass a comprehensive database reflecting the real-world performance of GL.iNet routers in various PCVR streaming scenarios.

I am committed to sharing technical data from rigorous testing, alongside video documentation that displays latency metrics during different stages of the streaming process via Virtual Desktop. The overarching goal is not only to accumulate a rich repository of user experiences but also to spark discussions that could steer towards optimizing our setups for an enhanced PCVR streaming experience.

Here’s a proposed template for sharing your insights:

Router Model: (e.g., Beryl AX (GL-MT3000), Opal (GL-SFT1200), etc.)

PC Specifications: (e.g., Processor, GPU, RAM, etc.)

VR Headset: (e.g., Meta Quest 2, Pico 4, etc.)

Streaming Application: (e.g., Airlink, Virtual Desktop, etc.)

Wi-Fi Connectivity: (e.g., AX at 1200Mbit/s, AC at 866Mbit/s, etc.)

Average Latency (Networking): (e.g., 20ms, 30ms, etc.)

Video Documentation: (Link to video showcasing the streaming process and latency monitoring)

Additional Observations: (Any other relevant information or peculiar findings during your testing)

My Experience:

Router Model: Beryl AX (GL-MT3000)

PC Specifications: Dell Alienware Notebook with a mobile 3070 GPU, 16GB RAM, 6-core i7

VR Headset: Meta Quest 2

Streaming Application: Virtual Desktop

Wi-Fi Connectivity: AX at 1200Mbit/s

Average Latency (Networking): 5ms

Video footage:

Additional Observations: The Beryl AX has exhibited stable performance during my gaming sessions, even at a distance of 5 meters with a clear line of sight. Currently, I am utilizing the firmware version 4.5 snapshot, as previous firmware versions were causing the router to shut down after a few minutes of gameplay. I am in the midst of experimenting with both enabled and disabled network hardware acceleration, although no significant differences have been observed thus far. My setup involves exclusively connecting my Quest to the 5GHz network, which is segregated from other networks. The router operates at maximum power, leveraging the AX bandwidth of 160MHz to ensure a seamless gaming experience.

Soon I’ll post results from my OPAL router.

I am thrilled at the prospect of unraveling the nuances of PCVR streaming with GL.iNet routers alongside you all. Your participation and technical contributions will be instrumental in illuminating the path towards optimized PCVR streaming solutions.

Looking forward to a riveting discussion and a treasure trove of insights!


I believe you mean Mbit/s?

1 Like

You are correct, thanks for pointing it out. Have a great day!

I don’t do VR, but your focus on performance + portability is of great interest to me as well. I’m putting together a cookbook of sorts for software/web devs who want to self-host all their tools and are nomadic or live in very small spaces. At this point all my daily-use network hardware is GL.iNet gear and it’s quite useful in this niche. Anyway my use case entails a lot of similar constraints and tradeoffs in the hardware + software stack as you, despite not dealing with VR.

Anyway, just letting you know I’ll probably keep an eye on this thread and if I can contribute, do so :slight_smile:

1 Like

Hello again, fellow community members and GL.iNet developers,

I want to provide an update and further emphasize a particular usage scenario that I believe has a substantial market potential awaiting to be tapped into. I continued my exploration with the Beryl AX router for PCVR streaming; however, despite running on firmware version 4.5, the router still shuts down/restarts after a few minutes of PCVR use. Unfortunately, this makes it difficult for me to recommend the Beryl for this specific use case, which is quite perplexing given its AX technology with 1200mbit connectivity.

Now, pivoting towards a broader perspective, the realm of PCVR streaming is burgeoning with the Quest 2 alone having sold over 20 million units. Yet, the market lacks dedicated and reliable hardware solutions to optimize the PCVR streaming experience. Today, Meta offers a D-Link VR Air Bridge, which creates a dedicated p2p Wi-Fi link between the PC and the Meta Quest 2, bypassing network congestion and interference common in typical home networks. However, this product is merely a repurposed D-Link hardware with a hefty price tag and a less-than-ideal software experience, as each configuration change necessitates a firmware flash.

The burgeoning PCVR community would greatly benefit from a dedicated solution that addresses the peculiar requirements of PCVR streaming. I envision a GL.iNet router tailored for this use case, offering a new “PCVR Streaming Mode” in the settings. This mode would configure the router as an access point, establishing a direct, wired connection between the PC and the current router/modem, ensuring the lowest possible latency and the most robust connection for PCVR streaming. Such a product could stand as a beacon in a market that’s ripe for innovation yet is currently underserved.

Moreover, the portability of GL.iNet routers, coupled with the ability to power them via a notebook’s USB port, presents a remarkable opportunity for creating a compact, travel-friendly PCVR setup. This, along with the capability to tether a mobile phone for internet access, outlines a comprehensive solution that addresses both the PCVR streaming and on-the-go internet connectivity needs.

I urge the talented developers at GL.iNet to consider venturing into this promising domain. With a well-designed product or a software update focusing on optimizing PCVR streaming performance, GL.iNet could significantly contribute to enhancing the PCVR experience for millions of users worldwide.

Thank you for your consideration, and I eagerly await the collaborative progress we can make in this exciting venture.

Maybe @dengxinfa could have a look? Thanks!

I notice that you said “coupled with the ability to power them via a notebook’s USB port”. The power consumption of Beryl AX is 5V/3A ( contain USB 5V/1A) . So the restarts issue may have some relevance with it.

1 Like

I appreciate your concern regarding the power consumption aspect when the Beryl AX is powered via a notebook’s USB port. However, I’ve also attempted to power the Beryl with the original power adapter provided in the box, and unfortunately, the restart issue persists. I monitor the power draw using a USB cable equipped with real-time wattage display, and it has never exceeded 1A, even though the router is rated for 5V/3A. This testing was conducted with all non-essential router functions such as adblock, VPN servers, and firewalls disabled to minimize power consumption.

The setup primarily involves connecting only the VR headset to the 5GHz band, with no other devices sharing this frequency. Additionally, the router is connected to the more robust port on the notebook that supports FireWire, capable of powering external monitors directly via USB-C. This arrangement is designed to ensure that adequate power is supplied to the router, minimizing any chances of power-related disruptions during PCVR streaming.

Regarding the restart behavior of the Beryl, post-restart, there’s a noticeable delay of almost 2 minutes where no LEDs are lit, which is significantly different from a regular boot-up when powered on initially. In a typical boot-up scenario, the LED lights up almost immediately. It seems like the router is executing some sort of process post-restart before it resumes normal operation, which isn’t observed during a regular boot-up.

This peculiar behavior alongside the persistent restart issue, despite various power supply methods, underscores the need for a deeper examination, I believe.

Thank you!

Hello everyone,

I am back with information about the Opal router. Here’s the test data:

Router Model: Opal (GL-SFT1200)

PC Specifications: Dell Alienware Notebook with a mobile 3070 GPU, 16GB RAM, 6-core i7

VR Headset: Meta Quest 2

Streaming Application: Virtual Desktop

Wi-Fi Connectivity: AC at 866MHz

Average Latency (Networking): 5ms

Video Documentation:

Additional Observations: The Opal router demonstrated more stability compared to the Beryl AX in my testing environment. It maintained a steady connection throughout the PCVR streaming session without any unexpected restarts or shut downs. The latency remained consistent at 5ms, mirroring the performance observed with the Beryl, albeit without the associated restart issues. This testing once again underscores the potential variability in performance across different router models, even when operating under similar conditions and settings.

The stability offered by the Opal in my testing scenario hints at a promising avenue for those seeking a dependable PCVR streaming setup, especially when on the move. I’m optimistic that the insights gathered from various community members could provide a well-rounded understanding, aiding GL.iNet in either refining their existing products or developing new solutions tailored for PCVR streaming.

Thanks for your reply. the restart behavior confuse me. Could you please give us the log?

1 Like

Kindly thanks for your deeply test.And you show us a new path of using our router. Some of our customer also use it in VR gaming. We will do a research about VR usage of our router.

1 Like

Hello! No problem, I’ll send it to you as soon as I fire up my Beryl again. Thanks!

Wow, that’s awesome! I’m part of a Brazilian VR gaming and user group with around 1200 members, and they often ask me for advice on dedicated VR Wi-Fi routers. I think your routers are amazing and I would love to recommend them to others. The thing about dedicated Wi-Fi streaming routers is that they need to replace the USB link cable, so the best way to use them is to connect only the VR headset and nothing else. That means the router should be cheap and have the right specs for a strong single connection to the headset. I really appreciate you taking the time to look into this and maybe add some new features to your routers.

I am also using Beryl AX GL-MT3000 for PCVR (Beat Saber) but I am facing stuttering issue, from occasional stutter to stutter every few seconds. I think it become worse when the gameplay is getting exciting (lots of boxes and movement).
I didn’t really encounter the random shutdown issue, though my gameplay time is quite short because of the stuttering issue. When I see the stuttering issue still exist, I will disconnect the PCVR to adjust the settings a bit and try again, but couldn’t get it to work without stutter. Maybe I can force myself to continue the session for longer despite the stuttering and see if the shutdown issue will happen to me…next time perhaps…

My laptop is connected to it via wired LAN and my Quest 1 connected via 5Ghz WiFi (bandwidth 80MHz, mode ac/ax, TX power max).
There is no other client within the same network, it is a separate network from my main router.
Currently running the latest stable firmware 4.4.6.

For my next PCVR session, I’m thinking to enable the Hardware flow offloading from the LuCI, not sure if it will help…

To add some additional info, when using the same setup but with my main router, the gameplay is smooth without stutter, so can pretty much rule out any issue with the laptop or quest 1.
I think the stutter is caused by sudden latency spikes…

Hi Alex, I have the same issues here. I wonder if the router overheats or something. I tried turning on hardware flow offloading in the network settings, but it didn’t help. I use a cheap Mercusys (AC12G) router as my main VR streaming device and it works much better than the Beryl.

Hi ASchneiderBR, I don’t think it is a thermal issue. I just had another session with it, and I put one of those handheld portable fan with built-in battery under the router, set it to max fan speed and blow right into the router from below. If the temperature reading at the system overview page is accurate, it is around 49~52 degree Celsius when playing, and stuttering still occurs. It should be something else.

I also tried without the fan, and continue playing for a while, with stuttering at the same time of course. After a while, I noticed the temperature increased to 60+. After a while more, the WiFi disconnected and within like 10s maybe, it was able to reconnect back successfully. Not sure if it is temperature related or because I have increased the bandwidth to 160Mhz and it is using DFS channel with the radar signal detection stuff going on…

I tried hardware flow offloading, still stuttering, same as what you mentioned. I also tried enable the packet steering option, can’t really tell if it made it worse or have no difference at all. I also tried disconnect the Internet access (unplug the WAN cable and disable multi-wan), makes no difference.

One thing I noticed is, when playing Beat Saber, if I try not to move my head at all, just keep it still and just wave my hands to slash those boxes, the stuttering is noticeably lesser. When I start to move around like how I usually play it, the stuttering becomes worse.

I suspect when I didn’t move as much, the game view remained mostly the same and thus the bandwidth usage was lower and when I moved around like crazy, the game view kept changing and the bandwidth usage also increased. Not sure if this theory is correct or wrong…

So just speculating, maybe this router couldn’t handle that high traffic load with small enough latency for smooth PCVR experience? Not sure how to test further on this and if there is any other config options that I can enable/disable to further optimize the performance in this scenario.

I have also exported the logs but haven’t checked it to see if there is anything related…

1 Like

Have you tried the 2.4G of the MT3000?

Unfortunately, 2.4ghz doesn’t have the necessary bandwidth for a decent VR streaming experience. You’ll need to use the 5ghz band for it. Thanks.

Turns out, there is something that can be done…

I was doing some research towards the direction where the latency increases upon heavy traffic load and came across something called “bufferbloat” and a few posts over at openwrt forum.

I’ll go straight to the point. You need to install SQM package from within LuCI (refer here https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm).
For the SQM setting, this is how I set it (the interface name points to the WiFi interface that VR headset connects to):

This may not be the best settings but it is good enough for me for now.
The stuttering is about 99% gone but at the same time I felt that the image quality dropped a little and occasionally will feel like the fps dropped slightly for a split second (still smooth but not as smooth, if you know what I mean).
This is far better than the previous freeze for half second and jump forward afterwards.

For the “Download speed” in Basic Settings page, I tried both 200000 and 600000, feels the same for me, not sure if it is because the WiFi interface (router) is “uploading” the video to the Quest headset, and that’s why “Download speed” here does not matter much…

For “Upload speed”, I tried 100000 also and it feels similar to 90000. I did try 150000 and it feels like the stuttering is coming back. Not sure if it is because my AirLink bandwidth setting is set to the default 100Mbps… maybe need to test further on this.

One thing to take note is, before I tried out this SQM, I have flashed the router with openwrt 23.05 firmware to see if the driver in that firmware will help (I guess you know the stuttering still occurs with that alone by now, because I went ahead and tried the SQM).
So I am not sure if it is needed to use openwrt 23.05 firmware in combination with SQM to make this work.
You can try install SQM within stock firmware and try it out first. If the stuttering issue still very bad, maybe can consider using openwrt 23.05 firmware + SQM.

Additional note, I have both Software/Hardware flow offloading and packet steering disabled.
I still use the handheld portable fan to blow into the router from below…

I think I’m gonna take a few days break before trying to tune the SQM settings further, tired :sweat_smile:


We ordered a Quest 2 . And will do some test next week. Hope we have more cooperation about the use of PCVR. :grinning:


Wow, that’s awesome! If you have any questions or need anything, just let me know. By the way, I highly recommend using Virtual Desktop. It has a great status overlay that shows you each step of the streaming process. Airlink has an overlay too, but it’s not very clear.

1 Like