# Lower-Latency Screen Updates over QUIC with Forward Error Correction
## 6 Empirical Results on Emulab
### Non-Streaming Updates  
The non-streaming updates workload is sending each update after receiving a request from the client. These requests can be any input from the client such as a mouse click or pressing a key of a keyboard. We set the gap between every two inputs to 300 ms in our experiments based on an example explained in [36] for the sequence of user inputs. In Figure 18, we present the CDF of the update response time in Figure 18a and the scatter plot of the message inter-delivery time in Figure 18b for the baseline setting, which as 0.5% packet loss, 100 ms RTT, 100 Mbps bandwidth, and BBR. The vertical lines in the message inter-delivery time shown in Figure 9b show the completion time of each experiment to deliver all 300 updates. We also mention the exact completion times in the caption, in addition to the number of points above the RTT for each delivery method. We present the same results for varying the packet-loss rate in Figures 19 and 20, varying the RTT in Figures 21 and 22, varying the bandwidth in Figures 23 and 24, and varying the CCA in Figure 25. We discuss all of these results in the Section \"Discussion of the Results of the Non-Streaming Updates Workload\". Figure 19: **Even for lower packet-loss rate than baseline, partial+FEC reduced update response time, message inter-delivery time, and the total completion time. ** Non-streaming updates, **0.1% packet-loss rate** (100 ms RTT, 100 Mbps, BBR): (**a**) CDF of update response time. (**b**) Message inter-delivery time in which the number of points above 100 ms is 14 for blue, 0 for gold, 1 for red, and 1 for black. Blue completed at 138.96 s, gold at 138.12 s, red at 134.51 s, and black at 135.61 s.  
Figure 20: **Partial+FEC reduced update response time and message inter-delivery time even more with higher packet-loss rate than baseline. ** Non-streaming updates, **1% packet-loss rate** (100 ms RTT, 100 Mbps, BBR): (**a**) CDF of update response time. (**b**) Message inter-delivery time in which the number of points above 100 ms is 119 for blue, 10 for gold, 1 for red, and 1 for black. Blue completed at 149.12 s, gold at 150.37 s, red at 137.64 s, and black at 135.77 s.  
Figure 22: **Partial+FEC reduced update response time and message inter-delivery time even more with higher RTT than baseline. ** Non-streaming updates, **200 ms RTT** (0.5% loss, 100 Mbps, BBR): (**a**) CDF of update response time. (**b**) Message inter-delivery time in which the number of points above 200 ms is 55 for blue, 9 for gold, 0 for red, and 0 for black. Blue completed at 180.24 s, gold at 185.66 s, red at 167.06 s, and black at 167.88 s.  
Figure 23: **Even for lower bandwidth than baseline, partial+FEC reduced update response time, message inter-delivery time, and the total completion time. ** Non-streaming updates, **10 Mbps bandwidth** (0.5% loss, 100 ms RTT, BBR): (**a**) CDF of update response time. (**b**) Message inter-delivery time in which the number of points above 100 ms is 79 for blue, 6 for gold, 0 for red, and 0 for black. Blue completed at 165.38 s, gold at 165.59 s, red at 158.97 s, and black at 158.2 s.  
Figure 24: **Partial+FEC reduced update response time and message inter-delivery time for higher bandwidth than baseline too. ** Non-streaming updates, **1 Gbps bandwidth** (0.5% loss, 100 ms RTT, BBR): (**a**) CDF of update response time. (**b**) Message inter-delivery time in which the number of points above 100 ms is 72 for blue, 5 for gold, 0 for red, and 2 for black. Blue completed at 146.51 s, gold at 146 s, red at 139.73 s, and black at 138.71 s.  
Discussion of the Results of the Non-Streaming Updates Workload  
1. **Partial order+FEC reduced the message-blocking time and inter-delivery time with the baseline setting (Figure 18):** The **CDF of the update response time** shown in Figure 18a shows that using partial+FEC with 5% redundancy rate (i.e., red, n/k = 1.05), the 99-percentile was 161.82 ms.