[TriLUG] ntpd misbehaving

[Michael Hrivnak]

Thanks.  The time zone is definitely correct, and this machine is on almost 
all the time.  I'm not really sure what's causing the problem to begin with, 
but ntpd should be able to compensate.  I'll look into what facilities it has 
for extraordinary circumstances.

Michael

On Tuesday 13 December 2005 02:56 am, Jon Carnes wrote:
> First be sure that your time-zone is set properly. I've had a laugh or
> two at clients who's machines kept creeping ahead after syncing with NTP
> - trying to slowly bring the machine up to the proper time for Iceland
> (or some such Eastern realm). NTP seemed to be working okay but one of
> two machines had clocks that zoomed ahead...
>
> Next, make sure your CMOS battery is okay - you might need to replace it
> - if the time loss happens during the time the machine is turned off.
>
> If the drift is fairly constant, then you can offset that with some
> fancy settings on NTP. I read the docs when setting up the Time Services
> for my ISP and they point to a few settings that are specifically
> designed for dealing with this situation (I haven't had to use them so I
> don't remember what they are).
>
> You can always do a manual sync at startup and then every hour. That
> should keep your workstation fairly accurate. Note: the docs argue
> against this...
>
> Good Luck - Jon Carnes
>
> On Mon, 2005-12-12 at 23:33, Michael Hrivnak wrote:
> > I run ntpd on a Mandriva machine in my home and sync the rest of my
> > machines to it.  It keeps very good time, and according to ntpq, the
> > offsets and jitters relative to higher-stratum machines are quite low.
> >
> > Then there's my desktop machine which has serious problems keeping time. 
> > It runs ntpd configured as so:
> >
> > /*------------------
> > #/etc/ntp.conf
> > server 192.168.12.1 prefer maxpoll 7
> > driftfile /etc/ntp/drift
> > multicastclient                 # listen on default 224.0.1.1
> > broadcastdelay  0.008
> > -------------------*/
> >
> > The clock tends to rapidly gain time.  24 hours after manually syncing
> > the time (ntpdate 192.168.12.1) and then starting ntpd, here's where it
> > sat:
> >
> > /*----------------
> > # ntpq -p
> >      remote           refid      st t when poll reach   delay   offset 
> > jitter
> > =========================================================================
> >===== 192.168.12.1    128.2.181.91     3 u   21  128  377    0.261 
> > -101968 1243.16 --------------------*/
> >
> > Apparently it's exceeding the maximum tolerable drift value, as seen here
> > in the logs:
> >
> > /*----------------
> > # zgrep ntpd /var/log/syslog.*
> > syslog.5.gz:Nov 20 02:03:54 localhost ntpd[3844]: synchronized to
> > 192.168.12.1, stratum=3
> > syslog.5.gz:Nov 20 02:08:11 localhost ntpd[3844]: frequency error -512
> > PPM exceeds tolerance 500 PPM
> > syslog.5.gz:Nov 20 02:12:29 localhost ntpd[3844]: time reset -1.441427 s
> > syslog.5.gz:Nov 20 02:12:29 localhost ntpd[3844]: frequency error -512
> > PPM exceeds tolerance 500 PPM
> > syslog.5.gz:Nov 20 02:22:09 localhost ntpd[3844]: synchronized to
> > 192.168.12.1, stratum=3
> > syslog.5.gz:Nov 20 02:22:09 localhost ntpd[3844]: frequency error -512
> > PPM exceeds tolerance 500 PPM
> > syslog.5.gz:Nov 20 02:29:37 localhost ntpd[3844]: time reset -1.529274 s
> > syslog.5.gz:Nov 20 02:29:37 localhost ntpd[3844]: frequency error -512
> > PPM exceeds tolerance 500 PPM
> > ----------------*/
> >
> > There are several questions here.  Foremost, what can I do to keep better
> > time?  Other questions are: What exactly is "jitter"? I can't even find
> > what it's units are.  My understanding is that the frequency error is in
> > milliseconds, but what does PPM stand for?  Why won't it tolerate a
> > greater frequency error?
> >
> > Thanks!
> >
> > Michael