[ntp:questions] NTP not syncing

Richard B. Gilbert rgilbert88 at comcast.net
Fri Dec 13 23:25:28 UTC 2013

On 12/7/2013 7:35 PM, Magnus Danielson wrote:
> On 12/07/2013 11:39 PM, Harlan Stenn wrote:
>> Magnus Danielson writes:
>>> The drift-file-accelerated lock-in isn't robust. Current behavior of
>>> response isn't very useful for most people experiencing it.
>> I'm not sure I'd agree with the word "most".  It's certainly worked very
>> well on hundreds of machines where I've run it, and the feedback I've
>> had from people when I've told them about iburst and drift files has
>> been positive except when they've had Linux kernels that calculate a
>> different clock frequency on a reboot.
> Experiencing the problem that is. When it works, it's a lovely tool.
> Sorry if the wording was unclear in that aspect.
>> There are at least 2 other issues here.
>> One goes to "robust", and yes, we can do better with that.  It's not yet
>> clear to me that in the wider perspective this effort will be worthwhile.
> Well, you can either choose a rather simple back-out method or if you
> think it is worthwhile a more elaborate method. Getting cyclic re-set of
> time is a little to coarse a method. I think it is better to back-out
> and one way or another recover phase and frequency.
>> The other goes to the amount of time it takes to adequately determine
>> the offset and drift.
>> With a good driftfile and iburst, ntpd will sync to a handful of PPM in
>> about 11 seconds' time.
>> We've been working on a project to produce sufficiently accurate offset
>> and drift measurements at startup time, and the main problem here is
>> that it can take minutes to figure this out well, and there is a
>> significant need to get the time in the right ballpark at startup in
>> less than a minute.  These goals are mutually incompatible.  The intent
>> is to find a way to "get there" as well as possible, as quickly as
>> possible.
> Getting the time in the right ball-park is by itself not all that hard.
> However, frequency takes time to learn and getting phase errors down
> quickly becomes an issue. NTP has as far as I have seen reduced loop
> bandwidth and at the same time reduced the capture range, and whenever
> you reduce the capture range you need to have heuristics to make sure
> you back-out if things get upset. Recovery of old state is good, but one
> needs to make sure that you don't loose that robustness.
> As for method of locking in quickly, that can be debated on in length.
> Cheers,
> Magnus

It has been debated!  It will probably be debated for the next thirty
or forty years.  There is something about the topic that seems to
to encourage debate! ;-)

More information about the questions mailing list