On 2012-06-06, Julien Ridoux <jul...@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=&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.
So, taking a chance to explain, instead were are again fed a puff diet of advertising. > > 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 And this says "A good-quality GPS with consistently good satellite visibility can cost many thousands of dollars by the time you have persuaded the building supervisor to mount it on the roof and run a cable to your office. Oh, and it will take you six months to make it happen?minimum" Sheesh. Try $50 and 15 min. A Sure gps pointing out an east facing window 5m below the roof stably gives its pulse per second with us accuracy. One would have a lot more faith in the system were the hype not so obvious. > > 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 questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
