The logs from our Azureus clients running on PlanetLab nodes provide a detailed view of a narrow slice of the system. To obtain a picture of the broader system, we inserted online statistics collection into the Azureus CVS tree. Using its recent neighbor set, each node computed its neighbor error and stability statistics on demand when probed. We present results from Azureus end-hosts running version 4D+H.
Figure 8 ``live (all)'' illustrates the data from a crawl of 9477 end-hosts. We exclude live nodes with fewer than 10 percent of the maximum 512 neighbors because their metrics are skewed to a very small percentage of the network. The data show that the bulk of the Azureus system experiences accuracy similar to clients running on PlanetLab. However, the error on the greater Azureus network has a long tail: at the 95th percentile, its accuracy is 76 percent worse. As we discuss in Section 7.1, we conjecture that the high rate of churn causes much of this difference in the tail.
In order to hint at the exigencies caused by running ``in the wild'' as opposed to safely in the lab, we compared the statistics from live Azureus nodes to those from our simulated embeddings of the Azureus latency matrix. In Figure 8, we compare live and simulated relative error. The data show a significant gap between live and simulated performance. (Prior work using the same simulator found simulations of PlanetLab mirrored live results .) The medians of the relative error distributions are 26 percent and 14 percent for live and simulated coordinates, respectively, a difference of 45 percent.
The data suggest that network coordinates have been partially tamed, but can be made substantially more accurate, and, therefore, more useful for distributed applications that would like to make cheap, quick decisions between providers of the same service. We show how the current level of accuracy affects these anycast decisions in the following section.
Jonathan Ledlie 2007-02-23