We have been working on making tests for VR Cloud gaming under certain network conditions. First we have tried this out in a lab environment using NetEm (a network emulator) to apply up to 300 Ms of RTT (Round-trip time). We are currently using the game “Serious Sam VR: The Last Hope”.
When doing the tests we have encountered a major problem. For RTT of 150 Ms and above, when network condtions have been applied for 10 seconds or more, the performance breaks and frames go as low as 4 FPS. When removing the delay with NetEm and reapplying it the performance returns to normal with the applied delay and normal frames. But again after some time it breaks if run for some time.
With this we were wondering what could be causing this problem?
We ask this question primarly to the Cloud XR developers. If you want some more context and information about the issue just ask and we will try to provide it.
so are you introducing 300ms latency on one direction, 150 on all packets (so 300 round trip)?
I know we’ve done some limited testing of latency and bw issues, but I’m not sure how far we pushed the stress tests. Clearly something like CloudXR cannot function well/properly with a 300ms RTT. Poses are completely off, pose estimation would be extreme… that said, it should be ‘delayed’ feedback, rather than completely breaking down. Logs from client and server might indicate what’s going on, I’m not sure. Otherwise we’d need to try to set up an equivalent test environment in-hose to try to reproduce locally. There are a lot of tuned algorithms under the hood of the networking layer to handle bandwidth issues, latency issues, dropped packets, etc. I can imagine in some extreme pathological case either one specific feature is going awry, or two or more features are negatively interacting (like mic+speaker echo feedback…).
If you’d please pass along the logs, and clarify exactly how the latency is being introduced into the system, that would help us begin to evaluate the issue.
I am answering on behalf of SamuelLarsson, as we are both researchers working in this experiment. The way we setup our lab environment was: An AccessPoint (router) ----- LinuxServer (runningNetem) ----- WindowsGamingPC (running Steam VR and CloudXR Server). We have tested an Oculus Quest V1, which was connected to our access point. We have a baseline delay between 1-2ms in our setup.
We applied netem Monodirectional or UPLink ( in the connection between LinuxServer and WindowsGamingPC). We have tested three conditions with constant delay of 75ms; 150ms; and 300ms; for the duration of 90s each. The context of the test for the results described below, were done by just staying in the steamVR environment (where you see the store page, and can select a game).
The WindowsGamingPC is an intel i7, with 32GB of RAM, with RTX 2070 (laptop). The starting of CloudXRClient was: “-s 192.168.50.157 -tle -tqs” and for the server: “-tle -t”
For the 75ms, there was no issues with the video quality rather than the effect of delay (actions such as head rotation and hands were slightly delayed) .
Files: CloudXR Client QoS Log 2023-04-27 20.24.41.csv (7.4 KB)
For the 150ms, after 20s of connection there are a severe video degradation, everything literally freezes, making it impossible use the service.
FilesClient: CloudXR Client QoS Log 2023-04-27 20.26.47.csv (4.6 KB)
I am sending attached logs from both server and client. You can distinct between the tests since they were done at minute 24 (75ms); minute 26 (150ms); minute 28 (300ms).