[ntp:questions] Offset is always increasing

Riccardo Castellani 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 
>>>>> value,

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>
Newsgroups: comp.protocols.time.ntp
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 
>>>> why
>>>> you are using them.  Leaf systems never need it and most intermediate 
>>>> ones
>>>> don't.
>>>>  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 
>> to
>> this server even if master source clock is unavailable, these 3 rows 
>> permit
>> 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 
>> don't
>> " .... 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 
>>>> suddenly
>>>> 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 
>> value,
>
> Please explain "keeps this value".
>
>> log shows every 20 minute 'synchronisation lost' while drift value is 
>> about
>> 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 
>> clock
>> 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
> http://lists.ntp.org/listinfo/questions 



More information about the questions mailing list