-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathResults.tex
55 lines (48 loc) · 4.04 KB
/
Results.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
\section{Results}
\subsection{Test 1: \acrfull{e2e} Latency}
\label{sec:res:t1}
\begin{table}[h!]
\begin{center}
\caption{\acrfull{e2e} Latency (ms)}
\begin{tabular}{ |c|c|c| }
\hline
\multicolumn{3}{|c|}{\acrfull{e2e} Latency (\acrshort{ms})}\\
\hline
\hline
Local without \acrshort{vr} & Local \acrshort{vr} & Cloud \acrshort{vr}\\
\hline
75-80 & 90-100 & 145-150\\
\hline
\multicolumn{3}{|c|}{Effective performance difference}\\
\hline
- & +25\% & +87.5\%\\
\hline
\end{tabular}
\end{center}
\end{table}
Initial measurements show that the \acrshort{e2e} latency of the Cloud \acrshort{vr} prototype is about \textbf{87.5\%} higher than a normal application on a local machine and about \textbf{50\%} higher than a \acrshort{vr} application on a local machine. As before, it is important to mention that the measurement from the Cloud \acrshort{vr}
prototype includes all the hardware and software latency of two machines, as well as the network latency between those. Furthermore \acrshort{vr} games are frame locked to match the display refresh rate of the \acrshort{hmd}. In the case of this test, the maximum \acrshort{fps} are 90, since the display of the \acrfull{hmd} (Vive Pro) has a refresh rate of 90\acrshort{hz}.
It should be noted that lower \acrshort{fps} and \acrshort{hz} impact the test negatively. Since the sensor measures changes in luminance, a higher update rate in-game as well as a higher display refresh rate would display changes sooner and as such result in a lower \acrshort{e2e} latency. For example: An example test from NVIDIA runs Counter Strike Global Offensive on a local machine with $\sim$350 \acrshort{fps} and a 144\acrshort{hz} display and reported an average \acrshort{e2e} latency time of 27.6\acrshort{ms}. Comparing this to the ''Local without \acrshort{vr}'' test that runs at 90\acrshort{fps} and a 90\acrshort{hz} display and has a latency of $\sim$75\acrshort{ms}, one can see clear performance differences.
\subsection{Test 2: Network Latency}
\label{sec:res:t2}
Testing with Wireshark \parencite{wireshark} revealed that the \acrfull{rtt} for a single packet is \textbf{5-6 ms}. Wireshark measures \acrshort{rtt} for a network connection as the latency between a data packet and the subsequent acknowledgment packet. This is supported by data collected from the CXR \parencite{cloudxr} software, which measured similar results.
Comparing this to the recorded \acrshort{e2e} latency and 'Frame Time in CXR' latency it is revealed that the network latency has an impact of \textbf{$\sim$3.3\%} on the \acrshort{e2e} latency and an impact of \textbf{$\sim$26\%} on the latency of a single frame.
To my knowledge the Cloud XR software primarily uses UDP as its network protocol for transferring user input, video and audio. It also uses TCP for transferring information about the server and client when a connection is established.
\subsection{Cloud XR Software statistics}
\label{sec:res:t3}
\begin{table}[h!]
\begin{center}
\caption{Cloud XR software statistics}
\begin{tabular}{|c|c|c|c|}
\hline
Frames Per Second & Frame Time in CXR (\acrshort{ms}) & Client Queue Time (\acrshort{ms}) & Average Video Rate (kbps) \\ \hline
90 & 21-22 & 5-9 & 20-30 \\ \hline
\end{tabular}
\begin{tabular}{|c|c|c|c|}
\hline
Est. Avail. Bandwidth (kbps) & Bandwidth Utilization (\%) & Jitter (\acrshort{us}) & Round Trip Delay (\acrshort{ms}) \\ \hline
300-500 & 3-4 & 17 & 5-6 \\ \hline
\end{tabular}
\end{center}
\end{table}
The following measurements were recorded during a play test with an example scene from Thales. These statistics are generated by the CloudXR software when launching it with the -qos-stats command. The most interesting statistics is 'Frame Time in CXR' which is the time a single frame spends in the Cloud XR software. This measurement is taken from the moment the server receives the eye texture from the client, to the moment the eye texture leaves the Cloud XR library on the client. Additionally the 'Client Queue Time', which is the time decoded frames spend for de-jittering to account for network jitter, and the round trip time are included in this measurement.