[ntp:hackers] Which ntp driver?
GDowd at symmetricom.com
Mon Apr 3 17:15:37 UTC 2006
To tell the truth, I'm subscribed to all ntp lists and I don't usually
differentiate the source of the initial ??s. But, of course, you are
correct about the venue.
Having said that, I don't think you are correct about burst/iburst. The
essential reasoning behind the burst mode of operation is quite
applicable to refclock drivers with the current architecture. The
iburst patten allows the refclock driver to quickly fill the sample
queue to get the daemon to select, step and start. I have seen cases
where a config with a gps refclock and a handful of stratum 2 boxes in
the config with iburst will usually select the s2 peers first, then it
seems to have a hard time switching over to the local refclock
occasionally. Maybe the clockhopping mitigation gets in the way? I
haven't looked into it. Modifying each of the drivers to create psuedo
burst modes would allow the same effect but require more code changes
and duplication of effort at the edges of the code. Also, the current
limitation on minpoll that I mentioned also applies.
gdowd at symmetricom dot com (antispam format)
Technologist, TT&M Div.
"The current implementation is non-obvious and may need to be improved."
From: Danny Mayer [mailto:mayer at ntp.isc.org]
Sent: Sunday, April 02, 2006 7:54 AM
To: Greg Dowd
Cc: questions at support.ntp.org
Subject: Re: [ntp:questions] Which ntp driver?
Some of this really belongs in hackers and some in the ntp WG.
For example I don't think that burst/iburst has a real meaning for a
refclock since it's constantly feeding ntpd data.
Greg Dowd wrote:
> Dare I admit that I haven't climbed the Wiki mountain yet? It seems
> to be a contentious issue. Having said that, I'm all for notes on
> application and suitability of the refclock drivers as well as common
> usage. It would be nice after the release comes out to review, or
> debate, the future of refclock drivers and their format. Dave's How
> build a refclock driver has been around for quite a while and is not
> quite accurate anymore. Moreso if the configuration structure
> Of course, no one wants to change the existing stuff and possibly
> break a legacy application but maybe we could deprecate some of the
> Things I have thought about (in no particular order):
> Do they all have to work forever?
> Could we get burst/iburst to apply -or- Is there any reason to cap
> minpoll. on a refclock (w/in reason) Are we stuck in pll mode with
> high update rates. Can I use a different filter on a refclock?
> Is there a limitation on the number of useful samples I can capture
> per poll (e.g. acts) Does the prefer keyword work properly for
> refclocks? (to prevent
> Can we please stop getting year from the host processor (when year is
> available in driver) [make -g work for refclock] Clarify the required
> data in refclock driver (and what is
> dynamic/static) [e.g. I change refid on fly] Add a private memory
> pointer to refclock structure to hold my data.
> Greg Dowd
> gdowd at symmetricom dot com (antispam format) Technologist, TT&M Div.
> Symmetricom, Inc.
> "The current implementation is non-obvious and may need to be
More information about the hackers