# Lower-Latency Screen Updates over QUIC with Forward Error Correction
## 6 Empirical Results on Emulab
### Non-Streaming Updates
However, the 99-percentile of total (i.e., blue) was 325.26 ms. Increasing the redundancy rate to 10% (i.e., black, n/k = 1.1) did not make a significant change, as 5% was enough for loss recovery. As shown in Figure 18b, the 99.95-percentile of the **message inter-delivery time** was 113.5 ms for blue, 97.91 ms for gold, 1.47 ms for red, and 1.79 ms for black. Furthermore, partial+FEC with 5% redundancy **completion time** was 11 s less than total. 2. **Partial order+FEC improvements increased as the packet-loss rate and RTT grew (Figures 18-22):** Increasing **packet-loss rate** from 0.1% shown in Figure 19 to 0.5% shown in Figure 18 to 1% shown in Figure 20 showed greater improvements in partial+FEC for both the update response and message inter-delivery times. For example, as shown in Figure 20, the 99-percentile of the update response time was 164.19 ms for partial+FEC with 10% redundancy rate (i.e., black, n/k = 1.1), 316.94 ms for Partial+FEC (n/k = 1.05, red), 318.02 ms for partial (i.e., gold), and 319.88 ms for total (i.e., blue). The 5% redundancy rate of Partial+FEC (n/k = 1.05) caused a lower recovery rate compared to Partial+FEC (n/k = 1.1) with a high packet-loss rate of 1%. Also, as we increased **RTT** from 50 ms shown in Figure 21 to 100 ms shown in Figure 18 to 200 ms shown in Figure 22, partial+FEC could reduce the update response time and message inter-delivery time as a function of the RTT compared to total and partial delivery. For example, as shown in Figure 22, the 99-percentile of the update response time was 272 ms for both partial+FEC (n/k = 1.05) and partial+FEC (n/k = 1.1), while it was 422 ms for total delivery. Figure 25: **Partial+FEC reduced update response time, message inter-delivery time, and the total completion time for CUBIC CCA. ** Non-streaming updates, **CUBIC** (0.5% loss, 100 ms RTT, 100 Mbps): (**a**) CDF of update response time. (**b**) Message inter-delivery time in which the number of points above 100 ms is 68 for blue, 13 for gold, 0 for red, and 0 for black. Blue completed at 159.68 s, gold at 157.12 s, red at 150.32 s, and black at 147.66 s.  
3. **Partial order+FEC improvements remained across different bandwidth values (Figures 18, 23, and 24):** Partial+FEC could help reduce both the update response and message inter-delivery time for all three different values of **bandwidth** in our experiments, from 10 Mbps shown in Figure 23, to 100 Mbps shown in Figure 18, to 1 Gbps shown in Figure 24. For example, the number of messages with an inter-delivery time higher than 100 ms was 79, 61, and 72 for total v.s. 2 or less for partial+FEC with 10 Mbps shown in Figure 14b, 100 Mbps shown in Figure 9b, and 1 Gbps shown in Figure 15b, respectively. 4. **Partial order+FEC reduced latency with both BBR and CUBIC CCA (Figures 18 and 25):** Figure 25 shows the update response and message inter-delivery time for **CUBIC** CCA. Considering the results with BBR and the same other network parameters (i.e., loss, RTT, and bandwidth) in Figure 18, we can see the increase in the message inter-delivery time of partial+FEC in Figure 25 but still with better results compared to total and partial delivery. For example, the number of points above 100 ms is 68 for blue, 13 for gold, 0 for red, and 0 for black in Figure 25b. 5. **FEC Overhead:** Figure 26 shows the FEC overhead with n/k = 1.05 and n/k = 1.1 rates in terms of update response and message inter-delivery time as we set the packet-loss rate to 0%. Partial+FEC had no considerable negative impact on latency, especially with n/k = 1.05. Comparing Figure 26b and Figure 17b shows that the FEC overhead had less impact on the latency of the non-streaming workload. The reason is that since there was a 300 ms gap between every two consecutive updates in non-streaming, the overhead of FEC for each update did not have an impact on the next update.