|
Figure 10(a) shows the median time elapsed between subscription generation and new replica creation as we scale the number of nodes in the peer-to-peer scenario (results for the edge-server scenario are similar and are ommitted here). The error bars on the top line show the 95th percentile of discovery latencies and the other lines break down the latency into the components required to: (1) route the subscription and a matching publication to the rendezvous point in Mercury, (2) send the match back to the subscriber, and (3) fetch and construct the new replica from the node owning the primary. The remainder of the discovery delay is comprised by computational processing delay and is dependent on the machines in our particular testbed.
Recall that the median RTT in our emulated network was about 80ms. As expected, the time to deliver a matching publication remains constant at about 1/2 RTTs (40ms) and the time to fetch a replica is about 1 RTT (80ms). The component that scales with the number of nodes is the Mercury routing component which has been shown to be logarithmic in the number of nodes in the system. Though it is hard to see the trend in these results since our experiments only ran with a small to medium number of nodes, it is quite clear that the slope is not very steep. In absolute terms, even with 150 nodes in the system, the median discovery latency is only about 260ms without computational processing overhead and about 330ms with it. Figure 10(b) shows a cumulative distribution of the discovery delays for this point. Approximately 80% of the time, the delay is even under 500ms and excluding a few anomalies, always under 1 second.
Although interactive latencies exceeding 50-100ms may be noticable by players, discovery latencies are only incurred upon first discovering an intereting object. For example, when a player enters a new room or another player comes into the periphery of a player's visible area. Once a replica is discovered and created, it will be kept up to date through direct communication with the primary, so replica staleness will be tied to the latency distribution of the topology; in our Internet topologies, this one-way delay is less than 100ms over 95% of the time. We believe this distinction between discovery and update latency contributes to our observation that the gameplay does not feel degraded.
We also note that several proximity routing techniques proposed to reduce routing latencies in Distributed Hash Tables [21,16] could easily be applied to Mercury as well, reducing the latency of the routing component of the discovery time.