Robust Timing Over the Internet

ChelleChelle writes "The NTP (Network Time Protocol) system for synchronizing computer clocks has been around for decades and has worked well for most general-purpose timing uses. However, new developments, such as the increasingly precise timing demands of the finance industry, are driving the need for a more precise and reliable network timing system. Julien Ridoux and Darryl Veitch from the University of Melbourne are working on such a system as part of the Radclock Project. In this article they share some of their expertise on synchronizing network clocks. The authors tackle the key challenge — taming delay variability — and provide useful guidelines for designing robust network timing algorithms."

Comments

GPS

[dracocat]

How about GPS receiver + exact known location?

I would think just eliminating an unknown latency and replacing it with a known one (radio waves generally travel at a consistent rate) would get you a pretty accurate time. If you add one more known variable which is the exact location of the device, then you should be able to get an even more accurate time.

can't trust self if microsoft

[at10u8]

Microsoft refuses to consider the notion of clocks accurate to within 2 seconds.

PTPd?

[Jeremi]

I'm surprised the article didn't mention PTPd, which is an implementation of the IEEE 1588 precision time-synchronization standard. I was under the impression that was the standard way to solve this sort of problem when NTP wasn't enough.

Re:Trust yourself...

[ls671]

Network issues. If say, on average, once every 25 polls, ntpd doesn't get realistic data from higher stratum servers because of the network, don't let ntpd crank up the frequency to ridiculous values like it does when this occurs.

There are realistic values for the frequency on every machine with a good clock. It is ridiculous to set the frequency below or above these values.

Last time I checked, there is no way in ntpd to configure these values. The typical ntp guru reply will be: "Get a decent network connection". The author in TFA noted that such a "decent connection" is virtually impossible to achieve because of "variable delay". He also noted that it is sometime better to trust yourself, which is kind of what that script does.