[ntp:questions] NTP vs RADclock?

Julien Ridoux julien at synclab.org
Wed Jun 6 08:03:58 UTC 2012

On Wednesday, June 6, 2012 4:41:59 PM UTC+10, unruh wrote:
> On 2012-06-06, Harlan Stenn <stenn at ntp.org> wrote:
> > Bill wrote:
> >
> >> 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. 
> >
> > You are being harsh.
> Yes. I do not like hype. Parts of that doc are reasonable comparisons.
> Parts are pure hype. GPs do not cost thousands and take 6 months. Can
> they, sure, but that is not what he said. 
> Yes, your room might be in the basement, down a set of broken steps, in
> a locked filing cabinet with Beware the Tiger on the door. But most are
> not. Yes your system might have a clock rate  which varies by .1PPM under
> typical loads and temperature changes, but most are far worse. Yes your
> local network might have many ms delays, but most do not-- they are a
> lot better than that. 
> >
> > Your world is just as alien to many folks as the accurate world view
> > described in the report is for a significant number of other folks is to
> > you.
> ?? What accurate world view. 
> You read the quote. "Oh, and it will take you six months to make it
> happen-minimum" Minimum is word with a well defined meaning. Mine took 5
> min. 5 min is less than six months. So, it will not take 6 months
> minimum. It may take 6 months if you are unlucky. 
> >
> > There are commercial buildings where rooftop access is simply not
> > possible.
>  Yes, I suspect that the Empire State building might be
>  difficult if you have to get to the roof. But that was not what he
> said. 
> >
> > There are many locations that require union electricians and permits and
> > inspections to do the cable runs.  These "people" costs can dwarf the
> > equipment costs.
> >
> > There are many buildings where the quality of the "energy efficient"
> > window is good enough that a GPS antenna will not get a useful signal.
> Yes, and many that do not. And RADclock still have the same problem.
> RADclock needs an accurate time source in order to measure the local
> clocks. As does ntpd. As does chrony. While the feedback problems are
>  not as severe if you simply
> correct, rather than discipline the local clock, but then you also have
> to rewrite all the kernel routines that deliver the time. And "feed
> forward" means that you only get the right time after a lot of
> calculations. You cannot rely on reading the clock and getting a fast
> accurate result. 
> Radclock is a good idea. It needs to be tested in a fair way. And it
> needs to be described accurately. Talking about "feedforward" is all
> very well, except it means nothing. What is the algorithm they use to
> convert the raw count to a time? What is the algorithm they use for
> deriving the slope and offset from the measurements. What is the
> algorithm they use to determine the best estimate of the roundtrip time?
> They claim ntpd goes unstable. Under what conditions? What do they mean
> by "unstable"?  
> >
> > Similarly, there are towns that do a lot of gov't business, and getting
> > a CPA firm to audit the books for a company will cost about $3k/year,
> > because so many companies in town need them.  There are *many* other
> > places where that same audit will cost more than $10k/year because the
> > "volume" of business is simply not there, and only a "bigger" CPA firm
> > can do the audit (it requires peer-review, so the firm has to have a
> > number of CPAs on-staff to do this).
> Yes, an there are firms that pay $100 K because the brother in law needs
> his cut. Is that typical? Play fair. Don't overhype is what I am asking. 
> So lets take one of their points, the roundtrip asymmetry mitigation.
> ntpd takes the smallest of the last 8. chrony does a least squares fit.
> RADclock does what? From the hints it sounds like it is closest to ntpd. 
> But then there is the comments about one way timing ( the server sends
> out the signals, and then sometime  the computers send out two way
> signals so as to estimate the trip time. What is the purpose of the one
> way signals? You certainly have zero estimate of the delay on that that
> particular signal. 
> Tha Allan deviation presumes a very particular model for clock and drift
> noise. But the thermal oscillations are certainly not that kind of
> noise. They are correlated, they are tied to time of day, etc, and they
> dominate the rate noise in most situations. 
> "the RADclock, a bidirectional, minimum RTT-filtered, feed-forward-based
> absolute and difference synchronization algorithm" Yes, and ntpd is a
> bidirectional, minimum RTT-filtered, feedback based absolute and
> difference synchronization algorithm. Is feedforward really better than
> feedback especially under the conditions used in ntpd?  
> Is ntpd ideal? No. Is chrony ideal? Almost certainly not, but I believe
> it is better than ntpd. Is RADclock  ideal? I have no idea but I suspect
> not. They all need study and work, not hype.

Dear unruh (Dr. William Unruh?),

It seems there is a little misunderstanding, I hope you won't mind some clarification.

The article you keep quoting is a high level description of the work, and we have worked with ACM Queue editor and reviewers to provide an overview easy to grasp for the non-expert. This was what ACM Queue was after. Please view this article that way and not as a scientific paper. I believe you are well aware of synchronisation issues, and I understand your reaction, but again, you were not the targeted audience (and for what it is worth, yes, we also have cheap GPS receivers on our office window that took less than 15mn to set up).

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 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 happy to receive criticism from people who have interest in improving computer clock synchronisation. Please accept my apologies if my message offended you, I am sure we can pursue this discussion over a more private channel in a constructive way.

Julien Ridoux

More information about the questions mailing list