In the past few weeks, we've been busy deploying a new version of the RIPE Atlas infrastructure. These changes bring more measurements to you, and also pave the way towards "user defined measurements".
RIPE Atlas probes have been doing "built in" measurements since the inception of the system. In the initial version, these included ping measurements to various destinations (towards RIPE NCC infrastructure and some of the root name servers), as well as discovery of the first two hops of the uplink path.
Now almost all of the probes have already upgraded to a newer and much more powerful version of their firmware. Here's an overview of what this can do for you in the near future:
More built-in "ping" measurements
The new firmware has significantly more capacity to do measurements, so we extended the set that is executed by default. From now on we include almost all root name servers, with the exception of the ones that explicitly do not respond to ICMP echo requests (e, g and h). We also added more unicast destinations, namely parts of the RIPE Atlas controlling infrastructure. We also have the ability to change this set, if that is considered useful.
You can see the results of these additional measurements in your "my probe" page.
In addition to RTT measurements, we now also do traceroutes to these destinations, although with lower measurement frequency. It can be really handy to look into more details, if someone is interested in finding out why connectivity is as it is.
We'll expose the results of these measurements to the hosts shortly.
DNS (anycast) measurements
Each probe also does "anycast instance discovery" measurements. That means, for each root name server, we try to determine which instance of the name servers the probe ends up connecting to if it does a query. This allows us to build maps about root DNS server "gravity radiuses" that may never have been produced before, and which therefore give a unique insight into the client base for the root DNS operators. An example of such a map can be seen below:
Which probes see which instance (color coded) of k-root?
(purple: ams-ix, green: denic, red: linx, yellow: nap, white: tokyo, blue: other)
We'll make this data available to hosts too.
Coming soon: User Defined Measurements
The new features also allow probes to contribute to measurements that are not pre-defined, but are instead specified by users of RIPE Atlas (User Defined Measurements, or UDM). In order to make this scale and be useful to the community, we had to implement a number of complex components dealing with measurement scheduling, task distribution, data collection and visualisation, etc.. We've made steady progress on these. Soon we'll be able to perform beta testing on this feature and, after that, give general access to RIPE Atlas users to try out this new feature.
We'll be looking for beta testers for UDM during the upcoming RIPE 63 Meeting as well as after it. If you'd like to be included in this, please send a mail to email@example.com .
We plan to do beta testing for a few weeks, and enhance the system based on user feedback. If all goes well, we'll enable the UDM feature for all hosts in December 2011.
In the meantime, we'll give you new maps based on the already collected data:
- Root server preference map, based on RTT values
- The above mentioned root DNS anycast map
These features will continue to prove the potential of RIPE Atlas for the community.
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
Victor Reijs •
Would it be possible to have a method to have a limit on the amount of measurement traffic? I have the ATLAS probe on my 3G connection. At present the probe uses around 1 GByte per month and in some way this is a considerable amount (around 10% of my contract). I assume some thinking is needed how to restrict it, but hope this can be done (I am willing to think further on this;-). Thanks.
Hide one reply
Daniel Karrenberg •
This will bepossible in the UI shortly. Any host having real problems with the amount of data should contact firstname.lastname@example.org so that we can limit this until the UI feature is available.
Mike Hughes •
Quite like the DNS instance discovery - folks have tried to do this before, but I don't think they've had enough coverage to get anything beyond "expected" results.
Robert Kisteleki •
I'm going to give a talk at the RIPE63 MAT-WG about more details, especially the UDM feature. You can tune in to the webcast if you're not there personally.