Further Virtualisation Testing for the RIPE Atlas Anchor

Introduction

The RIPE NCC has decided not to offer multiple services on the RIPE Atlas anchor boxes because of non-technical reasons. You can learn more about those reasons in RIPE Atlas Anchors Pilot: Summary and Next Steps . Despite the fact that we are not moving forward with multiple services, we wanted to report the findings of our virtualisation investigations during the RIPE Atlas anchors pilot phase, detailed here.

In a previous report , we described the results of an investigation of three alternative virtualisation technologies in order to run multiple services on the RIPE Atlas anchor boxes.

The outcome of that investigation was that a container-based virtualisation technique could support a multi-service RIPE Atlas anchor solution. However, a few questions remained unanswered by this first project - primarily the sub-second time behaviour of a virtualised RIPE Atlas anchor - that we address here.

Next steps

A follow-up investigation was done by the RIPE NCC to address two remaining open questions:

• Is there a measurable impact of lost tick compensation in the accuracy of time keeping in the virtual environment used?

• Is time stability at the millisecond scale also sufficient for use of the virtualised anchor for reliable measurements?

A series of experiments were run with a small Python script that measures time drift by repeatedly pinging an external system (connected to the same local switch) and adding a random period of inactivity. These experiments were run with three average values for the inactivity period: 0.1, 1, and 10 seconds.

Results

The outcome of the described tests is given in the tables and illustrated by the graphs below.

The results of the measurements showed that there was no relevant difference in behaviour between a physical system and a virtual system. There was a small difference found in the measured elapsed time, in which the virtual system showed a .01 ms longer RTT. However, for the target function of the RIPE Atlas anchors, a timing accuracy of the order of a millisecond is considered more than sufficient. Please see below the results in more detail.

Table 1: Timing measurements (10 sec average wait time)

Table 2: Timing measurements (1 sec average wait time)

Table 3: Timing measurements (0.1 sec average wait time)

In the results from Table 3, we see a larger value for the max RTT for the physical system. This was due to a single outlier result; it was not further investigated.

Below are the graphs that illustrate the above table values for Table 2 (you can click on each image to enlarge it).

Conclusion

Based upon these results, we concluded that a virtualised RIPE Atlas anchor, built on OpenVZ, would allow us to provide multiple services, while at the same time use the same RIPE Atlas anchor system for reliable RIPE Atlas measurements.

However, the RIPE NCC has decided not to offer multiple services on the RIPE Altas anchor box for several non-technical reasons as outlined in another RIPE Labs article .