[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
> 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.
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