[ntp:questions] NTPD silently not tracking
unruh at invalid.ca
Tue Sep 3 16:14:56 UTC 2013
On 2013-09-03, David Lord <snews at lordynet.org> wrote:
> Magnus Danielson wrote:
>> On 09/02/2013 02:33 PM, David Lord wrote:
>>> Harlan Stenn wrote:
>>>> David Lord writes:
>>>>> Magnus Danielson wrote:
>>>>>> server ntp1.kth.se iburst maxpoll 7
>>>>>> server ntp2.kth.se iburst maxpoll 7
>>>>>> server ntp3.kth.se iburst maxpoll 7
>>>>>> server ntp1.sp.se iburst maxpoll 7
>>>>>> server ntp2.sp.se iburst maxpoll 7
>>>>> that seems too restrictive and possibly abusive if you do not
>>>>> yourself have control over those servers.
>>>> iburst is not abusive.
>>>> Perhaps you are thinking of burst?
>>> I was thinking about maxpoll 7 and the few stats that were
>>> given indicating the very poor reach for the configured
>> There is good network connectivity to all 5 servers.
>> If you advice us not to use maxpoll 7, then we naturally will learn from
>> it. I don't use it personally, but I didn't set this machine up. Would
>> be nice to hear your explanation thought.
>> However, when doing the ntpdc peers command (in interactive mode), it
>> had all 5 servers available, and was tracking one (as indicated with =
>> and * at the beginning of the lines, I was told this over phone, so I
>> don't have visual memory of it all). So, I don't think bad connectivity
>> was the cause. It looked to a non-NTP expert like it had peers, was
>> happy with offsets (albeit it looked unexpectedly good at 0) but just
>> was plain way off in time. It took multiples querries with ntpdc peers
>> before it reacted on the time-offset, started to display big offsets and
>> eventually clean up itself. ntpdate -q did expose the time error of 6 days.
> having a low maxpoll over an internet connection doesn't make
> much sense. Variable internet delays are better evened out with
> longer poll intervals. Effect of system temperature variations
It depends on what you are looking for. If you want a more accurate
rate, then longer poll intervals are good. If you want smaller offsets,
then lower poll intervals are good, but if for some reason you lose
connectivity the rate will be off and the clock will drift more.
> might demand shorter poll intervals but probably not as low as
> maxpoll=7. Having seen one of your recent posts it appears that
> some of your sources might be local and under your control in
> which case a low maxpoll for them might be understandable.
maxpoll 7 is 128 sec, ntpd throws away 7 of 8 so the effective poll
interval is 16 min and then ntpd only slowly changes the drift. So it
will be hours before the machine catches up to a temp increase. But
which time it may well decrease again. ntpd is very slow to respond to
changes. A shorter poll may well help. But on the other side, a shorter
poll means more network chatter. and can overwhelm the server. So do it
on your own servers (eg gps stratum 1).
> Without real diagnostics I have no idea what could be the cause
> of the problem. I've certainly never experienced a system that
> claims to be in sync at the same time as being 6 days off.
One really really needs to look at the log files to see what in the
world happened. It is virutally impossible that that occured over the
course of a year say, just by natural drift. A bad computer clock is out
by 100PPM and that would take 60000days, or 200 years to produce a 6 day
offset. And somehow I doubt his system has run for that long. What is
possible is that someone went ahead and altered the time and very soon
thereafter he looked and saw it was still insync (since no new packets
had come in ).
More information about the questions