[ntp:questions] ntp client over satellite and no CMOS battery

Bob Beers bob.beers at gmail.com
Thu Sep 8 15:09:18 UTC 2005


Thanks for the reply,

First off, let me know if the proper ettiquite is to reply only to the list,
or to both the responders and the list -- as I have done here.

Actually, as far as ntpd is concerned, it doesn't make that much
> of a difference. You'll avoid the worst problem so long as your
> clock is within 34 years of correct on startup (68 years with the
> latest ntp-dev code, and the upcoming 4.2.1-RELEASE version), and if
> you start ntpd with a "-g" option, it will handle larger than normal
> offsets on startup, and still keep running. Without "-g", it would
> refuse to run if the offset is more than 1000 seconds, which would be
> a problem.


Well, it does make a difference, as I'm using timestamps that need to
be with in few minutes, as soon as the first event is initiated. I don't
want to delay 64 (or more) seconds.

By the way, I saw this page
<http://ntp.isc.org/bin/view/Dev/DeprecatingNtpdate>
which mentions sntp as a replacement for simple query
(potentially useful in my case, I think), but it never
worked for me. SNTP client from ntp.isc.org <http://ntp.isc.org> seems not
recently supported.


> aside: ntpdate is deprecated, but perhaps a cron job or
> > script calling ntpdate once a <time period> until
> > year > 2000 would help overcome this problem.
> 
> You don't want to try to run ntpdate at the same time as ntpd.
> Run one or the other, but not both.


Right, I understand this, I was implying to try this as an alternative
to ntpd, not in addition.

> 2) in rc.local, after network is configured, call
> >
> > ntpd -g -N -q
> >
> > with ntp.conf (almost default)
> > server <0.some.ntp.server>
> > server <1.some.ntp.server>
> > server <2.some.ntp.server>
> > server <3.some.ntp.server>
> > #server 127.127.1.0 <http://127.127.1.0> <http://127.127.1.0> # local 
> clock
> > fudge 127.127.1.0 <http://127.127.1.0> <http://127.127.1.0> stratum 10
> > driftfile /etc/ntp/drift
> > multicastclient # listen on default 224.0.1.1 <http://224.0.1.1> <
> http://224.0.1.1>
> > broadcastdelay 0.008
> > authenticate no
> 
> This seems reasonably plausible to me, although I'm not that
> familiar with how the multicastclient stuff interacts with broadcast
> delay, etc....


If I remove the fudge, multicast, broadcastdelay, and authenticate lines
entirely, would that be better for my situation? I will only be pulling time
from remote server(s), nothing fancy.

 This definitely sounds weird. Normally, you wouldn't want to run
> ntpd just once on startup, and then have it quit. Normally, you'd
> want to run ntpd on startup, and then have it keep running to keep
> the clock well adjusted.


I am okay with starting it once on startup, with -g to allow for the initial
jump from Y2K, but I did not see that my system clock was ever updated.
That is: date continued to return values Y2K + uptime. I thought (perhaps
erroneously) that if I exited after the initial update, my clocks
would be kicked to close to current time, then I could restart ntpd to
keep the time really accurate, until another power cycle.



More information about the questions mailing list