ntpd and kernel message set_rtc_mmss: can't update

[Jeff Vian]

On Sun, 2006-10-22 at 11:46 -0700, Wolfgang S. Rupprecht wrote:
> "Rob Brown-Bayliss" <uncertain.genius at gmail.com> writes:
> > [root at localhost ~]# ntpq -p
> >     remote           refid      st t when poll reach   delay   offset  jitter
> > ==============================================================================
> > mu-relay1.masse 192.5.41.40      2 u   16   64  177  170.570  -798.72 12760.3
> > ns1.compass.net 128.250.36.3     2 u   14   64  177  112.739  -13008. 7668.06
> > cobol.appello.n 128.250.37.2     2 u   14   64  177  162.234  -897.55 11922.0
> > ntp.thistledown .GPS.            1 u   19   64  177  203.800  -3927.4 9253.24
> > gen2.ihug.co.nz 130.217.76.49    2 u   14   64  177  140.795  -7057.9 7349.37
> 
> Actually that looks good as far as ntpd synch-ing to outside servers
> goes.  The servers it is syncing to, or the network connection it is
> syncing over, on the other hand suck big-time.  Notice the "offset"
> fields all differ from one another by a very large number of
> milliseconds.  I see an offset of 0.7 0.8 3.9 7 13 seconds!  No 3
> servers seem to agree as to what time it really is.  Thats not good at
> all.  If your network connection is really overloaded (with up to a 13
> second delay in a packet), then ntp is going to have a very hard time
> setting the time on your system.
> 
> The "reach" is really a bitfield that shifts ones from lsb to msb so
> it should indicate how many of the last 8 packets it successfully got
> back.  When ntpd starts expect that number to count as such: 1, 3, 7,
> 17, 37, 77, 177, 377.
> 
> The next thing to watch for is the first column in the ntpq -p output.
> Eventually some +'s -'s and *'s will appear.  These are servers that
> ntp has synced with or are potential candidates.  If it is doing that,
> then all is ok.
> 
> > [root at localhost ~]# ntpdate
> > 23 Oct 06:15:35 ntpdate[3869]: no servers can be used, exiting
> 
> ntpdate when run from the command line needs the servers listed by
> hand.  I don't know why it doesn't grab them from ntpd.conf as a
> default, but it doesn't.  Just grab one or all the servers / peers
> listed in your /etc/ntp.conf file.  
> 
One of us must be a little confused here.
/etc/init.d/ntpd (which starts ntpd for you at startup) explicitly calls
nptdate prior to starting ntpd.  It first tries to use the step tickers
listed in /etc/ntp/step-tickers.  If it cannot use them then it falls
back to use the servers listed in /etc/ntp.conf.

On my system that means it does use ntp.conf since step-tickers is empty
and always has been. 

True, if you run ntpdate manually from the command line you need to
provide the server for it to connect to.  How many of us really want to
do it that way?

> You won't be able to run ntpdate without the -d flag unless you stop
> ntpd.  I wouldn't stop it.  I'd just let it run for a day and try to
> get synced up.  The first time you run ntpd it will take a while as it
> is tuning the ntp.drift file for you.  It may take 2-3 days for the
> drift file to be adjusted.
> 
If ntpd sees the time as too far off it will refuse to continue trying
and that is not a good thing IMHO.

The easiest way I have found is to simply do a 
	service ntpd stop
followed by a
	service ntpd start
which takes care of running ntpdate to get any existing major time
discrepancies adjusted, then runs ntpd to fine tune it and keep it
accurate.

> -wolfgang
> -- 
> Wolfgang S. Rupprecht                http://www.wsrcc.com/wolfgang/
>