[ntp:questions] NTP vs RADclock?

skillzero at gmail.com skillzero at gmail.com
Thu Jun 7 01:34:09 UTC 2012

On Jun 5, 6:46 pm, Julien Ridoux <jul... at synclab.org> wrote:
> On Tuesday, June 5, 2012 9:12:42 AM UTC+10, E-Mail Sent to this address will be added to the BlackLists wrote:
> > David Woolley wrote:
> > > BlackLists wrote:
> > >> David Woolley wrote:
> > >>> This is the first I've heard of it, so I assume that it has never
> > >>>  appeared on this newsgroup, and its authors are not active here.
> > >> I recall it coming up before.
> > >> <http://groups.google.com/groups/search?q=radclock&scoring=d>
> > > I think you meant
> > >http://groups.google.com/groups/search?as_q=radclock&as_epq=&as_oq=&a...
> > > I think there were more references to Windows malware than time
> > > synchronisation without the comp.protocols.time.ntp constraint.
> > Yes, I mangled trimming the silly long link, thanks.
> > <http://groups.google.com/groups/search?q=radclock+ntp&scoring=d>
> Hi all,
> Being one of the main authors of the radclock software, I may be able to answer some questions directly. As mentioned earlier, I am not very active on this group, but will try harder in the future.
> As David pointed out, our website does not do a very good job at giving a plain overview of the algorithm. Nothing we have to hide (it is all in the source code), I just haven't had much time to keep it up to date lately. I think it is a fair comment and will try to provide more content as soon as possible.
> A high level description of the algorithm and why we are using a feed-forward algorithm can be found here:http://queue.acm.org/detail.cfm?id=1773943
> In the meantime, this page (also not quite up to date) links to most of our publications on the topic:http://www.synclab.org/docs/
> More gory details about the algo used can be found in the following paper as mentioned earlier:
> "Robust Synchronization of Absolute and Difference Clocks over Networks"
> Independent assessment of the performance of RADclock is a topic that often comes up. I haven't come across any true independent one yet, but would be very happy to help anyone who is willing to give it a go. This being said, our methodology relies on 3rd party hardware time reference, and we really try to show ntpd, ptpd ... at their best and show experiments that cover a long enough period of time to be relevant. I honestly believe that it will be hard to produce fairer results. Details about the methodology are described in this paper: "A Methodology for Clock Benchmarking"
> Of course, absolute clock performance depends on many factors: server quality, network congestion, ... and when focusing on LAN, polling vs. interrupt policy of the OS when retrieving packets from the network card. Consequently, any number quoted should be understood in the particular context of the experiment. I have managed to have ntpd show clock error variability below 10 mus on a LAN with low latency NICS and a stratum-1 server on the LAN. This number is obtained against hardware time reference comparison. However, what matters to us is the robustness of the solution over a long period of time, and not a pure absolute performance over a 1 hour period or less. In all cases, we take extra care to compare different synchronisation daemons under same conditions to ease comparison.
> From a user point of view, some of the advantages of using radclock are:
> - similar or usually better performance than ntpd and ptpd under many different conditions
> - much higher robustness against network congestion, change of routes, server errors, disconnections ...
> - two clocks in one: robust wall clock time, and extremely accurate difference clock to measure short term intervals
> - the possibility to 'replay time'. For example, this could be useful to improve the timestamps of log files created on different machines and collated for post mortem analysis.
> - use standard protocols, NTP and IEEE 1588 (although the later is still experimental and not released yet)
> To finish this long message, we have worked towards having the support for radclock be part of the FreeBSD kernel, and things are almost finished there. I believe this will give more opportunities to try radclock and make independent assessment and provide feedback. I hope to have time to get started on a similar effort on Linux soon-ish.
> Thanks for taking the time to look at the synclab.org website and to provide some feedback. I will try to take all of this into account in the next iteration.
> Julien Ridoux

Thanks for response. It would be great to have a simplified
description of the algorithm. I've read most of the docs on the
synclab site. I'm trying to synchronize several devices to a reference
clock of a similar device rather than to a true wall clock time of a
real NTP server. I can't use the RADclock code directly because it's
GPL so I'd like distill the algorithm down to something I can
implement from scratch. I'd like to adapt my current NTP client and
server code to use RADclock so I can compare performance. I'm aiming
for 10 microseconds or less of sync on a wireless LAN with a fast
initial sync time (less than 5 seconds, but I can send many packets
close together if needed). I haven't been able to get even close to
this with my current NTP code (Ethernet is close, but WiFi introduces
a lot of variability). Some of the key points seem to be:

1. Feed forward: Use raw TSC instead of the time value adjusted by the
algorithm. Is there more to this? Should raw TSC values be used for
offset sync calculations or should the raw TSC be scaled by the latest
adjusted rate (which would seem to be partially feed-back vs fully
feed forward)?

2. Separate offset sync from rate sync. What I wasn't sure about is
why the rate sync would be so much more stable than offset sync since
they seem to both come from the same packet exchanges. Is the
advantage that the rate sync is smoothed over time whereas the offset
sync isn't?

3. Use only the lowest RTT samples. NTP also does this so I wasn't
sure where the advantage was here.

4. Weight samples by their RTT. There's some mention of this in the
documents, but I wasn't sure what the algorithm was for determining
the weights or adapting them as conditions change (e.g. if network
load increased for a long period of time, which would also cause RTT's
to increase due to queuing in routers, etc.).

Are there other key aspects of the algorithm that I'm missing?

More information about the questions mailing list