[ntp:questions] Offset is always increasing

Mischanko, Edward T Edward.Mischanko at arcelormittal.com
Fri May 24 05:12:39 UTC 2013


 
> -----Original Message-----
> From: questions-bounces+edward.mischanko=arcelormittal.com at lists.ntp.org
> [mailto:questions-
> bounces+edward.mischanko=arcelormittal.com at lists.ntp.org] On Behalf Of
> Riccardo Castellani
> Sent: Thursday, May 23, 2013 11:03 PM
> To: questions at lists.ntp.org
> Subject: Re: [ntp:questions] Offset is always increasing
> 
> > ntpd probably never touches it. What is the time on the file ls -lga
> > <driftfile>
> I think it's impossible, yesterday I reset file content.
> 
> > Did you see me suggesting that you plot the stuff from your log files?
> > Look at /var/log/ntp/loopstats and peerstats.
> > from the forvmer get the drift correction. From the latter the offsets
> > Plot them to see what is happening. History is important, despite the
> > design philosophy of ntpd.
> 
> I'm using HP-UX so I cannot see /var/log/ntp/loopstats and peerstats,
> I can see only log file which I defined into ntp.conf.
> Does it exist tool which read log and plot it ?
> 
> 
[Mischanko, Edward T] 

Yes, Try removing these 3 lines or putting ## at the beginning of them for
testing.  Ntpd ignores lines in the configuration that begin with #.

> What do you think to remove these 3 lines from all ntp servers how other
> ntp
> technicians are suggesting me ?
> 
>  server 127.127.1.0
>  fudge 127.127.1.0
>  restrict 127.127.1.0 mask 255.255.255.255
> 
> 
> 
> 
> 
> 
> 
> 
> ----- Original Message -----
> From: "unruh" <unruh at invalid.ca>
> Newsgroups: comp.protocols.time.ntp
> To: <questions at lists.ntp.org>
> Sent: Thursday, May 23, 2013 10:36 PM
> Subject: Re: [ntp:questions] Offset is always increasing
> 
> 
> > On 2013-05-23, Riccardo Castellani <ric.castellani at alice.it> wrote:
> >> You thought right, xntpd says "synchronisation lost" every 20 minutes,
> >> drift
> >> file is about 855, xntpd daemon is running from about 1 year.
> >> In these days I
> >> made several days and I restarted daemon and I waited a day to analyze
> >> offset.
> >>
> >> When I says "stable" I'm refering to value into drift file because I
> see
> >> always
> >> the same value, that is about 855.
> >
> > ntpd probably never touches it. What is the time on the file
> > ls -lga <driftfile>
> >
> >>
> >> Do you suggest me to measure specific drift
> >> of my hardware clock by script as documented into ntp.org, Known
> Hardware
> >> Issues, 9.1.6 (Mac Mini and other machines having poor TICK settings) ?
> >> I test
> >> identical server (which has same problems) I delete the drift file and
> I
> >> restart daemon, after 2 hours :
> >
> > You can tell almost nothing in 2 hrs.
> > Did you see me suggesting that you plot the stuff from your log files?
> >
> > Look at /var/log/ntp/loopstats and peerstats.
> > from the forvmer get the drift correction. From the latter the offsets
> > Plot them to see what is happening. History is important, despite the
> > design philosophy of ntpd.
> >
> >
> >>
> >>
> >> ntpq -pn
> >>
> >>      remote           refid      st
> >> t when poll reach   delay   offset    disp
> >>
> >>========================================================================
> ======
> >>
> >> *10.2.3.5    193.204.114.233  2 u    9   64  377     0.61   -0.350
> >> 0.11
> >>
> >> 127.127.1.1     127.127.1.1     10 l    8   64  377     0.00    0.000
> >> 10.01
> >>
> >>
> >> I'm worried because after many months I wouldn't like to find the same
> >> behaviour.
> >> I have no other software to discipline time.
> >>
> >>
> >>
> >>
> >> Riccardo Castellani
> >> wrote:
> >>>>>>>> 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
> >>
> >>
> >>>>>>>> I thought you said xntpd reset it about every 20
> >> minutes. How can it
> >>>>>>>> then have been stable for several months?
> >>
> >>>>>>>>
> >> (If ntpd weren't correcting it, but only measuring it, I would suspect
> >>>>>>>>
> >> that you had some other time discipline software that was doing a slow
> >>>>>>>>
> >> adjustment to the clock and which thought the time was 700 to 800ms
> out.)
> >
> > _______________________________________________
> > questions mailing list
> > questions at lists.ntp.org
> > http://lists.ntp.org/listinfo/questions
> 
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions


More information about the questions mailing list