[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:

> Dave,
> 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.
> H
> --
> --
>>>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 mailing list