public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: William Kenworthy <billk@iinet.net.au>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] extreme clock drift / openntpd won't sync
Date: Thu, 01 Sep 2005 06:56:33 +0800	[thread overview]
Message-ID: <1125528993.8779.30.camel@rattus.localdomain> (raw)
In-Reply-To: <20050831221333.GA8710@raw-sewage.net>

First add the line "tinker panic 0" to the top of ntp.conf (for ntpd,
not openntp)  This allows it to step when outside normal parameters.
Otherwise it will register the time difference but wont try and correct
it.  If it is drifting faster than the allowable correction rate, it
will slowly move to the threshold where ntp will stop correcting.

Second, some combinations of hardware (dell for me :( , kernels and
applets will cause this.  They "pause" the system when they
access /proc/something.  The one that did it for me was the gnome batt
stat applet (which works ok these days).  There's also some reports of
KDE applets doing the same thing.  If possible stop X and all X apps and
monitor to confirm this is the area where the cause lies.  Start by
removing any applets that might be causing the problem.  

It sometimes happens that various config files and states contribute to
the problem as when the clock is drifting so fast they set wild values
when trying to correct.  Boot to level 1 (simplifies things) so ntp is
not running, remove /etc/adjtime and /etc/ntp.drift then set the clock
using hwclock.  Reboot and see how it goes.  Never had much luck trying
to sort it out when the system was fully up.

BillK

On Wed, 2005-08-31 at 17:13 -0500, Matt Garman wrote:
> My system clock is running extremely fast... so fast that even
> openntpd (apparently) can't catch up!
> 
> I tried (oh how I tried) to get the "regular" ntp package to work.
> I could correct my clock using ntpdate, but I could never get ntpd
> to sync with any servers (see notes (*) below).
> 
> So I got fed up with trying to get it to work, and thought I'd have
> better luck with openntpd (which is much simpler).  
> 
> As far as I can tell, openntpd *is* working, as I have many lines in my
> syslog that look like this:
> 
> Aug 31 17:00:36 [ntpd] adjusting local clock by -344.003180s
> 
> However, the clock is still drifting---not as fast as it does with no
> ntp daemon running, but noticeably (it's gained about 5 minutes in less
> than 24 hours).  Note that without any ntp daemon running, my clock will
> gain about 10 minutes per hour!
> 
> I have a hunch that whatever prevented the "regular" ntpd from syncing
> is preventing openntpd from properly keeping the clock in sync.
> 
> So, my questions are: (1) what would cause my clock to run so fast?  And
> (2) why can't any ntp daemon keep correct time?
> 
> Thanks,
> Matt
> 
> 
> 
> (*) If anyone is interested in the plight I had with ntp, here is some
> info:
> 
> This is what my /etc/ntp.conf looked like:
> 
> restrict 127.0.0.1 nomodify
> server pool.ntp.org prefer
> server 0.pool.ntp.org
> server 1.pool.ntp.org
> server 2.pool.ntp.org
> server 127.127.1.1
> fudge 127.127.1.1 stratum 10
> driftfile /var/lib/ntp/ntp.drift
> logfile /var/log/ntpd.log
> 
> After starting ntpd, and waiting a while, ntpq results looked like
> this:
> 
> ntpq> pe
> 
> remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
> frigg.interstro 138.195.130.71   3 u   21  128  377  124.592  -3950.7 1260.34
> cteha.ulp.co.il 192.114.62.249   3 u   26  128  377  201.236  -4670.9 1715.95
> Time4.Stupi.SE  .PPS.            1 u   79  128  377  129.134  -1668.9 1996.01
> Time1.Stupi.SE  193.10.7.246     2 u   21  128  377  128.697  -3962.7 1253.70
> *LOCAL(1)        LOCAL(1)        10 l   13   64  377    0.000    0.000   0.001
> 
> ntpq> assoc
> 
> ind assID status  conf reach auth condition  last_event cnt
> ===========================================================
> 1   57708  9014   yes   yes  none    reject   reachable 1
> 2   57709  9014   yes   yes  none    reject   reachable 1
> 3   57710  9014   yes   yes  none    reject   reachable 1
> 4   57711  9014   yes   yes  none    reject   reachable 1
> 5   57712  9614   yes   yes  none  sys.peer   reachable 1
> 
> 
> -- 
> Matt Garman
> email at: http://raw-sewage.net/index.php?file=email
-- 
William Kenworthy <billk@iinet.net.au>
Home!
-- 
gentoo-user@gentoo.org mailing list



  reply	other threads:[~2005-08-31 23:02 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-31 22:13 [gentoo-user] extreme clock drift / openntpd won't sync Matt Garman
2005-08-31 22:56 ` William Kenworthy [this message]
2005-09-01  0:36 ` Matt Randolph

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1125528993.8779.30.camel@rattus.localdomain \
    --to=billk@iinet.net.au \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox