[ntp:questions] Tighter regulation?

Mischanko, Edward T Edward.Mischanko at arcelormittal.com
Sun May 26 04:05:16 UTC 2013


> -----Original Message-----
> From: questions-bounces+edward.mischanko=arcelormittal.com at lists.ntp.org
> [mailto:questions-
> bounces+edward.mischanko=arcelormittal.com at lists.ntp.org] On Behalf Of
> David Woolley
> Sent: Saturday, May 25, 2013 7:57 AM
> To: questions at lists.ntp.org
> Subject: Re: [ntp:questions] Tighter regulation?
> 
> Mischanko, Edward T wrote:
> 
> >
> > I would modify the current algorithm with an exception that if offsets
> >  exceed 1 millisecond for more than one polling cycle, then, polling
> will be
> >  reduced by one interval, else, continue normal operation.
> >
> 
> Whilst I still think the OP is trying to make the statistics look good,
> rather than have good time keeping, I can sort of see two feature
> requests here:
> 
> 1) a tinker option to specify an assumed maximum jitter, which will
> allow the user to put in a long term jitter statistic for their system,
> rather than having ntpd work it out for itself.
> 
> 2) a tinker option for a panic level of offset, where, it is assumed to
> be so improbable, given the specific noise statistics of the actual
> system, that it should immediately be considered to be due to a local
> clock frequency error.  Measurement noise is often non-gaussian, so it
> unlikely to be safe to make this a fixed multiple of the value in item
> (1).  If this is to be used without filtering by the minimum delay
> filter, it will need to be a lot higher than the filtered value, as the
> minimum delay filter will take out most one off spikes in offset.
> 
> I am not volunteering to write the code for these, and I do have concern
> that an urban folklore will develop in which in become it becomes common
> advice to set them excessively low.
> 
[Mischanko, Edward T] 

The frequency ppm does not oscillate nor does the clock offset over short periods of time.  Reducing maxpoll to 8 is effective is solving my issue.  I agree that we should not be chasing noise spikes.

> However, I still feel that, if the underlying problem is clock frequency
> drift, the primary fix is to address the cause of that drift, and the
> stop gap solution is to reduce maxpoll.  If it is almost anything else,
> the offset changes do not indicate a timekeeping error and should not be
> acted upon.
> 
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions


More information about the questions mailing list