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

David L. Mills mills at udel.edu
Wed Oct 5 20:28:55 UTC 2005


Brian,

Thanks for plain ASCII, which is much easier for me to read. Wish 
everybody else did that.

There already is a mechanism to read the NTP status and statistics using 
the ntp_gettime() and ntp_adjtime() system routines if your kernel has 
NTP support. Solaris, Tru64, FreeBSD and (option) Linux have such support.

Dave

Brian T. Brunner wrote:

> calldelay does not look like what you want... it just sticks a hard wait between the first two attempts to get the time from the server, regardless of whether the first succeeded, regardless of whether the rest of the iburst will do what you want iburst to do.
> 
> Suggest: 
> make the ntpd starter script wait for a minute after starting ntpd, and check the time.  If the year is still 2000, loop back up to restart ntpd.
> have the application wait on the year changing from 2000 to something else before starting the real work.
> 
> missing from the ntpd design(?): some system-readable TimeIsGood flag set by ntpd for applications to use where they must have trustable time.
> alt: TimeStateIs flag with values of LOST (no net, no idea what time it is), SEEKING (found a source, getting time), and SYNC (time is good)
> alt: SEEKING_n for n ranging 1 to the "minimum acceptable set size" for your site; SYNC means the highest minimum has been met.  This allows different applications to decide when is the time sufficiently good for that application.
> 
> just my thoughts.
> 
> Brian Brunner
> brian.t.brunner at gai-tronics.com
> (610)796-5838
> 
> 
>>>>Bob Beers <bob.beers at gmail.com> 10/04/05 04:18PM >>>
> 
> Hello again all,
> 
> While it was an interesting excursion, I wonder if I could bring
> this thread back around to the original topic?
> 
> There have been a few other threads recently which touch a bit on
> the same subject matter and I have learned a bit from them.
> 
> sync immediately
> ntpd for dummies
> ntpd and hwclock
> 
> I still have not completely solved my original problem,
> which I will restate now:
> 
> 
> A linux unit (basically an ntpd client) without a hwclock battery
> lives on the remote side of a satellite connection. Every time
> it comes alive from power cycle, the hwclock sets the system clock
> to 2000-Jan-01.
> 
> Under ideal circumstances, the network is available before the client
> starts ntpd -g -N, and all is well; the system clock is set to
> current time very quickly. I have a 3 line ntp.conf on the client:
> 
> server 172.16.87.11 <http://172.16.87.11> iburst
> driftfile /etc/ntp.drift
> logfile /var/log/ntp.log
> 
> ( where 172.16.87.11 <http://172.16.87.11> is my linux ntpd server on the
> internet side
> of the satellite using four pool.ntp.org <http://pool.ntp.org> servers, and
> restricted
> to only serve time to my clients )
> 
> However, sometimes, the network link does not become available until
> after ntpd has been started. If the initial iburst to the server
> doesn't get any reponse, and then the network does become available,
> it takes several minutes vs. a few seconds to get the clock set.
> 
> Q1: Can I modify that behavior?
> 
> If not, I have in mind to run a cronjob which tests network connectivity
> to the ntpd server and (re)starts ntpd, to get the quick clock adjust once
> the network is available. I would still need to detect when the state
> was "good", and then could set my hwclock manually (optional) and cancel
> the cronjob.
> 
> Better ideas most welcomed.
> 
> This is important (to me) because I have an app to run on the client
> which uses timestamps, and I want to delay starting the app until after
> the system clock is set, but, of course, as quickly as possible. And
> I don't want to delay the rest of the boot process, just the one app.
> 
> Thanks,
> 
> -Bob
> _______________________________________________
> questions mailing list
> questions at lists.ntp.isc.org 
> https://lists.ntp.isc.org/mailman/listinfo/questions
> 
> *******************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
> 
> This footnote also confirms that this email message has been swept
> for the presence of computer viruses.
> 
> www.hubbell.com - Hubbell Incorporated
> _______________________________________________
> questions mailing list
> questions at lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
> 




More information about the questions mailing list