[ntp:questions] Re: Ref clocks and polling intervals
stenn at maccarony.ntp.org
Fri Dec 3 01:41:41 UTC 2004
I'm not talking about an implementation.
All "we" want to have is an easy way to have ntpd "believe" an attached
refclock "Real Soon".
We thought an easy, intuitive way to tell this to ntpd is to use the
"iburst" keyword in the config file.
Nobody is suggesting using any implementation details.
My guts tell me it must be possible to implement this.
I see several scenarios:
A) the refclock is sane and we have a "good" drift file
B) the refclock is insane and we have a "good" drift file
C) the refclock is sane and we have a "bad" drift file
D) the refclock is insane and we have a "bad" drift file
First, my premise is that in the last 3 cases, the fact that there is
a problem doesn't really matter.
I say this because "soon enough" the following will happen:
- the local ntpd may notice, and adjust its "state" accordingly
- clients will notice, and ignore us (if they are properly configured)
Therefore, the interesting case is case A, and I submit:
- that if we can "quickly" get the time from the refclock and believe it,
- then we should be able to get equivalent startup times between an ntpd
that uses iburst with stable servers/peers and an ntpd that uses the
iburst keyword with an attached refclock.
I know I have played fast and loose here.
I'll have more after I dig in to the code a bit and do more thinking.
In article <cojgnn$6q2$1 at dewey.udel.edu>,
David L. Mills <mills at udel.edu> wrote:
>IBURST won't work with the drivers I wrote, since they use the median
>filter in the driver interface to reduce jitter necessary for
>submillisecond precision. Some of those drivers once did use IBURST to
>avoid the need for a per-second call from the driver interface, which is
>now a feature. The former use was really awkward and is to be avoided.
>Dumb drivers that don't care much about submillisecond precision can use
>IBURST in the same way as ordinary peers. You are welcom to experiment,
>but not with my drivers. I wouldn't be surprised if something breaks.
>Considering the grief I've had rationalizing the ntp_proto.c code and
>the definitive flow charts, you don't get to change either.
More information about the questions