[ntp:questions] Re: How to force ntpd to set time first time if clock is withhin +-128ms range

Barry Bouwsma ntp at news.netscum.dyndns.dk.INVALID
Wed Sep 10 18:24:45 UTC 2003


[Sorry to have to use an invalid e-mail, but I've been offline and
 have yet to re-establish myself thus far, kill me if you must]


"Sarbjit Singh" <singh at image.dk> scribbled:

> > > The ntpdate program can't run when the ntpd is running on the clients since
> > > the port is used by ntpd. I would then need to stop ntpd before running
> >
> > ntpdate -b
> >
> documentation it points to not to use the ntpdate, but use ntpd. The ntpdate
> program will retire from distribution some time in the future. Functionality
> of ntpdate has been build into ntpd. That is the main reason not to use
> ntpdate.
> 
> So I still looking for how to force ntpd to reset time first time it start,
> and continuing to discipline the clock afterwards. That would achieve our
> goal to having a precision of +-1 ms after short time.

Being offline for a while, I've had to deal with this.  The only time
sources I have offline are a half dozen radio clocks (DCF77 signal connected
to serial or parallel ports), and at boot I've wanted to get in sync with
real time as quickly as possible, ntpdate-like -- but of course, ntpdate
doesn't work with radio clocks the way ntpd does (or if it doesn't, I don't
want to know about it).

So I've used roughly year-old development ntpd code, hacked to add another
flag used by ntpdate-emulation-mode, which does the opposite of `-x' --
the option to always slew (never step) the time, while I want to always
step the time regardless of offset.  If my machine comes up just under
100msec off, I want to correct that immediately.

In order to do this, I run a hacked `ntpd -q' first, wherein I've
added an option, for lack of a better idea `-X', to always-step-never-
slew, which works great for me.  Then it promptly exits, at which time
I start a new ntpd that then operates normally to hold things within
close tolerance.  Normally.  Unless the first step was bogus for some
reason, or its own first step was bogus.  Which has happened once.  Out
of plenty of boots.

I've mulled over the idea of trying to make this hack work for normal
ntpd operation as well, but I don't know the innards well enough to
know if I can just continue along after that first step, or if the
data gathered before that time adjustment will poison the following
data.  Anyway, I also use a couple different config files for startup
and normal operation, so it's fine with me to continue to needlessly
run two instances.

I think this might be sorta the idea you're looking for, which perhaps
could be incorporated into ntpd (if not already, as noted the last
code I looked into is pretty much a year out of date) as more than a
hack...


barry bouwsma




More information about the questions mailing list