Slashdot Mirror


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."

2 of 178 comments (clear)

  1. Re:Ridiculous by Anonymous Coward · · Score: 5, Informative

    This sort of thing probably has something to do with it:

    http://www.nytimes.com/2009/07/24/business/24trading.html

  2. Re:PTPd? by apharov · · Score: 5, Informative

    (disclaimer: just finished my Master's thesis on a related subject) PTPd is ok, but not in itself up-to-date at the moment. It doesn't implement the most recent IEEE 1588-2008 standard, which has significant improvements compared to the 1588-2002. About the 1588 in general: its main selling point is the ability to do hardware timestamping (when using hardware with support!) of the two-way timing messages between master and slave. This eliminates the very significant timing jitter that happens in the software stack before the messages are timestamped. For reference, commercially available master-slave implementations using IEEE 1588 achieve synchronisation within tens of nanoseconds within LAN, and microseconds to tens of microseconds within WAN, depending on network conditions. So overall I think that while RADclock might be ok as an alternative between NTP and IEEE 1588, it doesn't really bring anything new to the table. Some of the stuff in the Rideaux/Veitch paper has also been used with IEEE 1588 for quite some time, for instance the filtering for fast timing packets is a necessity for accurate synchronisation with IEEE 1588.