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.
Danny 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 to > build a refclock driver has been around for quite a while and is not > quite accurate anymore. Moreso if the configuration structure changes. > Of course, no one wants to change the existing stuff and possibly break > a legacy application but maybe we could deprecate some of the drivers. > > 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 > ensembling) > 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. > www.symmetricom.com > "The current implementation is non-obvious and may need to be improved." _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
