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

Brad Knowles brad at stop.mail-abuse.org
Thu Sep 8 12:03:04 UTC 2005


At 5:27 PM -0400 2005-09-07, Bob Beers wrote:

>  1) in rc.local, after network is configured, call
>
>  ntpdate <some.ntp.server>
>
>  problem: if satellite modem comes up more slowly
>  than my unit, the ntpdate fails and clock is left
>  at CMOS default (Jan 01, 2000)

	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.

>  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.

>  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> # local clock
>  fudge 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>
>  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....

>  This doesn't seem to like the network delays/jitter. I can provide a trace
>  upon request, but the thing that most caught my eye was repeated
>  lines stating: combine offset nan.

	Sorry, I don't know the code or the algorithms well enough to be 
able to be of any help on this part.

>  Another question relating to this second method, if I may:
>  I thought the -q option would cause ntpd to exit after clock is
>  updated,

	It should, yes.

>           but it seems to keep running, and while kernel seems
>  to know the updated time (new processes show up in ps -auxw
>  with current time, the rest of the system (i.e. date) does not.

	You might have a child process left hanging around to do DNS 
resolution, but that should have exited at the same time as the 
parent.

>  Have I skipped some important setup step here?

	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.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.



More information about the questions mailing list