On Friday, June 8, 2012 2:00:33 AM UTC+10, unruh wrote:
> On 2012-06-07, Julien Ridoux <[email protected]> wrote:
> > On Thursday, June 7, 2012 2:26:54 AM UTC+10, unruh wrote:
> >> On 2012-06-06, Julien Ridoux <[email protected]> wrote:
> >> > On Wednesday, June 6, 2012 4:41:59 PM UTC+10, unruh wrote:
> >> >> On 2012-06-06, Harlan Stenn <[email protected]> wrote:
> >> > Dear unruh (Dr. William Unruh?),
> >> >
> >
> >> 
> >> >
> >> > I would encourage you to read the scientific papers we published. I am 
> >> > confident you will see the level of hype being much lower. The 
> >> > description of the algorithm you are requesting can be found in several 
> >> > papers. Repeating myself, the main one being : ""Robust Synchronization 
> >> > of Absolute and Difference Clocks over Networks". It does describe the 
> >> > algorithm in more details. It may not deliver all the details you are 
> >> > after (or be slightly outdated), but the code publicly available is also 
> >> > there for you to read. It is the ultimate reference after all.
> >> >
> >> 
> >> It would be nice to have a link to that publication, in particular not
> >> not one where you have to buy it. 
> >> And asking people to read the code is a cop out. I have tried hard to
> >> read the ntpd code for example, and the chrony code. While the latter is
> >> slightly (only sightly) better than the former, both are a real pain to
> >> figure out what is going on. Reading code is always a case of far fr too
> >> many trees for to see the forest. 
> >> 
> >> For others, I have found a copy at 
> >> http://www.cubinlab.ee.unimelb.edu.au/~darryl/Publications/synch_ToN.pdf
> >
> > Please note that the page http://www.synclab.org/docs/ I mentioned before 
> > has links to all publications but the most recent. Please click the "Full 
> > text" link to access the one of interest. I have updated most links for 
> > convenience and missing ones will be added with the next update to the 
> > website.
> >
> >> > It was not my intention to describe the entire algorithm in my previous 
> >> > message (it has been done in publicly available papers), but instead 
> >> > give some pointers and general answers to some of the questions raised 
> >> > earlier. My message did not intend to sparkle a heated discussion but 
> >> > instead try to provide honest answers to this group.
> >> 
> >> I am very confused by your graph comparing ntpd to radclock. The ntp has
> >> huge oscillations while from what I have read it is critically damped
> >> while what I see is a pretty high Q (of the order of 10 or so) in the
> >> graphs. Things I have not seen in my looks at ntpd. (Ntpd does have
> >> problems which I have spent time pointing out in the comparison with
> >> chrony) but oscillations like that I have not seen. Is this really ntpd
> >> or some stripped down testbed?
> >
> > I am assuming you are talking about figure 13 in the paper mentioned above. 
> > The version of ntpd used in this plot is the stock standard version shipped 
> > with FreeBSD 6.1 (this data set has been captured in late 2006). The 
> > machine used is a Pentium 3 @600MHz (now long dead), a DELL Optiplex GX1 
> > with an onboard 3Com 100 Mbps NIC. In this experiment, ntpd is configured 
> > as a broadcast client only listening to a stratum-1 server on the LAN.
> >
> > The broadcast configuration may be a cause for the large oscillations? I 
> > suppose ntpd experts may have an opinion on this.
> >
> > Another paper of ours (more recent) shows more comparisons of radclock 
> > agains ntpd under a variety of scenarios:
> > http://www.synclab.org/pubs/radclock_2012_TON.pdf
> > In particular, figures 8 to 11 show ntpd performance that may resemble what 
> > you have observed: no erratic behaviour on the LAN if the polling period is 
> > small enough.
> >
> > I would be interested in looking at a performance comparison of ntpd vs. 
> > chrony if you have one accessible. I will also try to start a comparison of 
> > chrony vs. radclock. It could be valuable to compare our findings. I have a 
> > fair few things on my plate these days, and this may get delayed a fair bit.
> 
> There is some on my page www.theory.physics.ubc.ca/chrony/chrony.html
> (note that there have been changes recently so that the time tracking of
> all the machines right now is a mess).
> 
> Miroslav Lichvar has also done extensive testing of ntpd vs chrony using
> a
> synthetic testbed (ie, the data is manufactured data but the algorithm
> is the same so that the system can be run at far faster than real time).
> I do not have the web references right now, but if you look back over
> the
> past year or so in this newsgroup for posts from him you will find the
> comparisons.
> 
> Note, it would be really good if you persuaded your newsposting program
> to put in line breaks, instead of sending out huge long lines of text.
> Some newsreaders simply throw away the ends of lines that do not fit on
> one line, making reading difficult. 
> 
> The polling behaviour of ntpd should make no difference to the
> "oscillations" since the time scale of the feedback loop is adjusted to
> the polling period so as always to keep it roughly critically damped
> (modulo the feedback problems introduced by the highly non-linear clock
> filtering algorithm) 
> .

Thank for the link to the performance page and the reference to Miroslav 
Lichvar. I will come back to you once I have run some performance comparison 
using chrony.

_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions

Reply via email to