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=&as_eq=&num=10&scoring=&lr=&as_sitesearch=&as_qdr=&as_mind=1&as_minm=1&as_miny=2012&as_maxd=1&as_maxm=1&as_maxy=2012&as_ugroup=comp.protocols.time.ntp&as_usubject=&as_uauthors=&safe=off > > > > 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 _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
