[ntp:questions] Offset is always increasing
ric.castellani at alice.it
Thu May 23 03:48:30 UTC 2013
>>>>> I can see usually offset increases until 700 or 800 and it keeps this
It keeps this value means it's stable for many months, it's doesnt change
----- Original Message -----
From: "David Woolley" <david at ex.djwhome.demon.invalid>
To: <questions at lists.ntp.org>
Sent: Wednesday, May 22, 2013 10:50 PM
Subject: Re: [ntp:questions] Offset is always increasing
> Riccardo Castellani wrote:
>>>> Remove these until you get it working, and then only re-add them if the
>>>> system is serving time to downstream systems and you really understand
>>>> you are using them. Leaf systems never need it and most intermediate
>>>> It can sometimes cause problems on the server on which is configured.
>> Doy you think these 3 rows can create problems ?
> There are some cases where the local clock appears to be able to outvote
> external servers when those servers give a significantly different time.
>> Server will give time to my clients and I'd like clients continue to sync
>> this server even if master source clock is unavailable, these 3 rows
>> this behaviour.
> There are some cases where this may be valid, but if the server is
> drifting badly, it would be better to let them free run, with the last
> correction value. The big disadvantage when service other systems is that
> they never get to know that the upstream time source has failed.
> In any case, current versions will take around a day before they give up
> on the uptream server.
>> Why you syas: " Leaf systems never need it and most intermediate ones
>> " .... I' don't understand.
> Leaf systems (ones that don't serve anything else) will free run when they
> loose all sources, using the last frequency correction. Defining the local
> clock will not change that. Non-leaf systems will free and won't diverge
> greatly for a significant amount of time. They will know that they are
> free running.
>>> What version of ntpd are you using. Some vendors failed to track the
>>> renaming back to ntpd, but, otherwise,
>>>> you have an extremely obsolete version
>> My xntpd daemon is version 3, as defined by RFC-1305 but also retains
>> compatibility with version 1 and 2 servers as defined by RFC-1059 and
>> RFC-1119, respectively.
> Obsolete. Version 4 has been current for many years now.
>> OS is HP-UX B.11.31 U ia64
> I am pretty sure that version 4 pre-dates ia64. There is no good reason
> for running anything else on ia64 (even if w32time is version 3!)
>>>> If the offset smoothly ramps up, you have a broken clock. If it
>>>> jumps, especially if there is fixed interval between jumps, >> you have
>>>> something else trying to discipline the clock, usually a cron job that
>>>> copies the time from the RTC.
>> I can see usually offset increases until 700 or 800 and it keeps this
> Please explain "keeps this value".
>> log shows every 20 minute 'synchronisation lost' while drift value is
>> 855. Problem could be "local clock high frequeny", what do you think ?!
>> What means 'a cron job that copies the time from the RTC' ? I tested
> "cron job" has the normal Unix meaning.
> On some Unix system, e.g, SunOS 4, and at least some versions of SCO Open
> Server, the system periodically copies the value in the "CMOS" real time
> clock, to the software maintained clock use by the OS. This could be a
> cron job, it could be a user space daemon, or it could be a function in
> the kernel itself.
> This normally results in the time tracking the server relatively
> accurately for some time, then suddenly jumping to a different time, which
> differs from the server time by about the same amount each time.
>> other 2
>> identical servers and behaviour is the same, it's very strange broken
>> for 3 servers.... I think.
> That suggests a software bug, in the OS, or a configuration problem.
> questions mailing list
> questions at lists.ntp.org
More information about the questions