[ntp:questions] Offset is always increasing

David Woolley david at ex.djwhome.demon.invalid
Wed May 22 20:50:25 UTC 2013


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.
> 
> 



More information about the questions mailing list