[TriLUG] ntpd misbehaving

[Jon Carnes]

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