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 ?
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.
Why you syas: " Leaf systems never need it and most intermediate ones don't
" .... I' don't understand.
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.
OS is HP-UX B.11.31 U ia64
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,
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 other 2
identical servers and behaviour is the same, it's very strange broken clock
for 3 servers.... I think.
thanks
----- Original Message -----
From: "David Woolley" <david@ex.djwhome.demon.invalid>
Newsgroups: comp.protocols.time.ntp
To: <questions@lists.ntp.org>
Sent: Tuesday, May 21, 2013 10:52 PM
Subject: Re: [ntp:questions] Offset is always increasing
Riccardo Castellani wrote:
server 127.127.1.1
fudge 127.127.1.1 stratum 10 # show poor quality
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.
20 May 14:38:20 xntpd[19386]: synchronized to LOCAL(1), stratum=10
20
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.
How can I solve it ?
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.
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
