[ntp:questions] Offset is always increasing
unruh at invalid.ca
Thu May 23 15:25:42 UTC 2013
On 2013-05-23, Riccardo Castellani <ric.castellani at alice.it> wrote:
>>>>>> 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
800 what? if the offset is greater that 125 ms, ntpd will step.
And you talk about offset of 800 and then drift of 835. Which is it?
ntpd cannot drift faster than 500PPM, so 800 or so is not possible if
that means ppm.
Units are extremely important in conveying information.
> ----- Original Message -----
> From: "David Woolley" <david at ex.djwhome.demon.invalid>
> Newsgroups: comp.protocols.time.ntp
> To: <questions at lists.ntp.org>
> Sent: Wednesday, May 22, 2013 10:50 PM
> Subject: Re: 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