[ntp:questions] Re: Ref clocks and polling intervals
David L. Mills
mills at udel.edu
Wed Dec 1 04:18:56 UTC 2004
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.
Harlan Stenn wrote:
> Please help me understand.
>>The burst functions conflict with some reference clock drivers which use
>>it for other purposes.
> First, generally speaking, I'm assuming we'd want this capability to be
> a choice for each refclock, not simply done for all refclocks without
> question. Given that...
> There seems to be 2 places we could implement this change.
> One is the refclock driver - we'd have to check to see if FLAG_IBURST is
> set in the peer structure, and if so, load the receive buffers such that
> the next poll of the driver would receive a "full load". I suspect this
> is a poor choice.
> The other place is in ntp_proto.c, where we already have code to
> iburst the "other side". In this case when we'd add the FLAG_IBURST
> test after the appropriate code branches that test true for FLAG_REFCLOCK.
>>>A number of us would like to use it to mean "initially get the time the
>>>refclock tells us ASAP."
More information about the questions