Comment maintenir un système informatique à l'heure dans la vraie vie. :)

« Different versions of RIPE Atlas probes maintain their clocks in different ways, and the differences are mainly caused by architectural differences.

There are currently four versions of RIPE Atlas measurement devices:
    * The small, black v1 and v2 probes were custom made. The main difference between the two is that the v1 probes have 8 MB of internal memory and the v2 probes have 16 MB. Both types of probes have a total of 16 MB of flash memory for storage. Note that we don't distribute these probes anymore. But there are more than 2,500 out there in the network.
    * The current v3 probes are based on TP-LINK TL-MR3020 routers. These probes have 32 MB of internal memory, 4 MB of internal flash and 4 GB of USB flash.
    * Finally, RIPE Atlas anchors are small servers that run the Centos Linux distribution and the RIPE Atlas probe code as an application on top of that.

[...]

RIPE Atlas anchors run an NTP daemon that synchronises with pool.ntp.org. The pool.ntp.org project is a big virtual cluster of timeservers providing NTP service for millions of clients. The RIPE Atlas code cannot set the time itself - anchor hosts must allow unrestricted access for the NTP protocol.

[...]

For v1, v2, and v3 probes the situation is a lot more complex. First of all, some of these probes are in an environment where the NTP protocol is blocked or filtered somewhere in the network. Additionally, those probes do not have a battery backed-up, real-time clock.

The lack of a battery backed-up clock requires some tricks to give a probe a sense of time shortly after it boots. The potential lack of access to NTP servers requires a fallback mechanism in case NTP is unavailable.

This fallback is integrated with the code that submits the measurement results. Every three minutes, probes will try to submit their measurement results to the RIPE Atlas infrastructure using an HTTP POST request. The probe then uses the timestamp in the HTTP reply to verify and, if necessary, correct its local clock. Basically, the probe checks whether its local clock is within two seconds of the controller's clock. If not, and the entire HTTP request took less than one second, the probe updates its local clock.

This mechanism is the only one the v1 probes use to synchronise their clocks. The reason is that the main memory on the v1 probes is too small to run a separate NTP daemon (ntpd). The v2 probes run an NTP implementation called 'ntpclient'. And v3 probes currently use OpenNTPD but will switch to ntpd in the near future.

In addition to keeping the clock of a probe synchronised, we also want to include in the measurement results whether the timestamp is likely to be accurate or not. For example, when a probe boots but does not have Internet access, it cannot set its clock - but the probe will still perform measurements. In that case, when the probe later reports the measurement results, it is important to know that the timestamps might be incorrect.

The way this is implemented is as follows. As described above, when a probe reports measurement results, it compares the timestamp in the HTTP reply with its local clock. If the time difference is less than two seconds and the entire HTTP request took less than one second, the probe records that at that time the clock was in sync.

When a probe generates a measurement result, it includes a field called 'lts', which stands for "last time synchronised". In this field, the probe reports the number of seconds that have passed since the probe last recorded that its clock was in sync. So in the ideal case, the values should never exceed 180, because probes report results every three minutes. A probe uses the special value -1 to indicate that, since it last rebooted, it never found its clock to be in sync. Note that this code runs not only on the v1, v2, and v3 probes, but also on the RIPE Atlas anchors. »

[...]

How accurate are the RIPE Atlas probes' clocks?
[...]

RIPE Atlas v1 (blue) and v2 (green) probes show similar behaviour. Some probes are more than two seconds from 0, but not many. Also, v1 and v2 probes show a similar distribution. We can conclude that the NTP client program that runs on the v2 probes doesn't have any effect, i.e. not running it in the v2 probes is likely to give the same results.

However, v3 probes (red) show an unusual distribution. As you can see in Figure 2 above, there is a thin spike in the middle, and the distribution of the rest of the v3 probes is not symmetric, but skewed a bit to the left.

[...]

This shows that the spike is a group of 557 v3 probes out of a total of 4,622 v3 probes that have their local clocks within 10 ms of ntp.atlas.ripe.net. In addition, most of the RIPE Atlas anchors (green) are also in that same range. Some v3 probes manage good time synchronisation, and it is not clear why the others don't. Regardless, it's important to note that this just means that some probes are more accurate, not that there is a problem with the less accurate probes.

Most RIPE Atlas anchors also have good time synchronisation. As mentioned above, anchors are synchronised to pool.ntp.org. This means that an asymmetric path between the anchor and ntp.atlas.ripe.net may skew results.

[...]

We are currently testing NTP measurements within the RIPE Atlas infrastructure and, once these tests are successful, plan to make them available as a new measurement type (in addition to ping, traceroute and DNS measurements) to RIPE Atlas users. These NTP measurements will be available from all RIPE Atlas probes towards one of the NTP servers. This will allow RIPE Atlas users to measure the time between a collection of probes and a specific target.

[...]

In general, almost all RIPE Atlas probes are within two seconds of UTC, which means their clocks are in sync with the RIPE Atlas infrastructure. Big outliers that fall outside this range have the 'lts' field set, which signals that the probe's state (with regards to its time synchronisation) is unknown.

A small group of v3 probes and most anchors are within 10 ms of UTC. We intend to switch to ntpd and pool.ntp.org for the v3 probes in the near future. At the moment it is not clear why the NTP client doesn't work on v2 probes and why the OpenNTPD works only on some of the v3 probes. »

Via http://seenthis.net/messages/344907