How RIPE Atlas Helped Wikipedia Users

Emile Aben — Jul 09, 2014 12:25 PM
Contributors: Faidon Liambotis
Engineers from the Wikimedia Foundation and the RIPE NCC recently collaborated on a project to measure the latency of Wikimedia sites for users worldwide. Together, we identified ways to decrease latency and improve performance for users around the world.

During RIPE 67, Faidon Liambotis (Principal Operations Engineer at the Wikimedia Foundation) and I got into a hallway conversation. Long story short: We figured we could do something with RIPE Atlas to decrease latency for users visiting Wikipedia and other Wikimedia sites.

At that time, Wikimedia had two locations active (Ashburn and Amsterdam), and was preparing a third (San Francisco), to better serve users in Oceania, South Asia, and US/Canada west coast regions. We were wondering about the effects on network latency for users worldwide for this third location and Wikimedia wanted to quantify the effect that turning up this location would have.

Some call this "stupid DNS tricks"; others find it useful to decrease latency towards websites. Wikimedia is in the latter group, and we used RIPE Atlas to see how this method performs.

One specific question we wanted answered is where to "split Asia" between the San Francisco and the Amsterdam Wikimedia location. Latency is obviously a function of physical distance, but also the choice of upstream networks. As an example, these choices determine if packets to "other side of the world" destinations tend to be routed clockwise or counter-clockwise.

We scheduled latency measurements from all RIPE Atlas probes towards the three Wikimedia locations we wanted to look at, and visualised which data centre showed the lowest latency for each probe. You can see the results in Figure 1 below.

Wikipedia latency mapFigure 1: Latency map. Probes are colored based on the data centre that shows the lowest measured latency for this particular probe.

This latency map shows the locations of RIPE Atlas probes, coloured by which Wikimedia data centre has the lowest latency measured from that probe:

  • Orange: the Amsterdam PoP has the lowest latency
  • Green: the Ashburn PoP has the lowest latency
  • Blue: the San Francisco PoP has the lowest latency

Probes where the lowest latency is over 150ms have a red outline. An interactive version of this map is available here. (Note that this is a prototype to show the potential of this approach, so it is a little rough around the edges.)

Probes located in India clearly have lower latency towards Amsterdam. Probes in China, South Korea, the Philippines, Malaysia and Singapore showed lower latency towards San Francisco. For other locations in Southeast Asia the situation was less clear, but that is also useful information to have because it shows that directing users to either the Amsterdam or the San Francisco data centre seems equally good (or bad). It is also interesting to note that all of Russia, including the two most eastern probes in Vladivostok, have lowest latency towards Amsterdam. For the Vladivostok probes, Amsterdam and San Francisco are almost the same distance, give or take 100 km. Nearby probes in China, South Korea and Japan have lowest latency towards San Francisco.

There is always the question of drawing conclusions based on a low number of samples, and how representative RIPE Atlas probe hosts are for a larger population. But having some data is better than no data in these cases, and if a region has a low number of probes, that can always be fixed by deploying more probes there. If you live in an underrepresented region you can apply for a probe and help improve the situation.

With this measurement data to back it, Wikimedia has gradually selected Oceania, Southeast Asian countries and US/Canada states/provinces to which RIPE Atlas measurements showed minimal latency to be served by their San Francisco caching PoP. The geoconfig that Wikimedia is running on is publicly available here.

As for the code that created the measurements and created the latency map, this was all prototype-quality code at best, so I originally planned to find a second site where we could do this, to see if we could generalise scripts and visualisation and then share.

At RIPE 68 there was interest in even this raw prototype code for doing things with data centres, latency and RIPE Atlas, so we ended up sharing this code privately, and have heard of progress made on that already. In the meantime we've put up the code that created the latency map on GitHub. Again, it's a prototype – but if you can't wait for a better version, please feel free to use and improve it.

Conclusion

If you have an interesting idea but have no time, or other things are stopping you from implementing it, please let us know! You can always chat with us at a RIPE Meeting, regional meeting, or any other channels. We don't have infinite time, but we can definitely try out things, especially ideas that will improve the Internet and/or improve the life of network operators.

0 Comments

Add comment

You can add a comment by filling out the form below. Only plain text is possible. Web and email addresses will be transformed into clickable links. Comments are moderated so they won't appear immediately.

Navigation
Related Items
NTP Measurements with RIPE Atlas

This article describes how RIPE Atlas probes and anchors maintain their clocks, and how accurate ...

Visualising Network Outages With RIPE Atlas

This article shows some prototypes of visualising network outages with RIPE Atlas using CartoDB.

Increased Reach of RIPE Atlas Anchors

Increasing the reach of RIPE Atlas anchors is one of the highest priority goals of RIPE Atlas Team. ...

Distribution of RIPE Atlas Probes

As the RIPE Atlas network continues to grow, it's useful for ambassadors and potential probes hosts ...

Proposing Making RIPE Atlas Data More Public

RIPE Atlas is now three years old, and is moving from a prototype to production service. Based on ...

more ...