[ntp:hackers] PPS, PPSAPI and pps_sample()
David L. Mills
mills at udel.edu
Mon Dec 13 16:48:09 PST 2004
So far as I know, the only testing with multiple instances of the atom
driver was on the Alpha with Tru64. That was primarily to see if the
kernel code worked properly. Lots of things go wrong when you use more
than one atom driver, like how to handle the prefer peer, what stratum
to use, what instance to send pps_sample() to and so forth. I can't make
any case to use more than one PPS signal to actually discipline the
clock other than as sanity check. The way it is now, the last instance
of the atom driver will be the one in charge. To avoid the clock select
algorithm getting in the way, put a noselect on any prior atom servers.
The unit numbers themselves haven't been used for years. The only reason
they are still there is a couple of clock drivers never were converted
to the "new style" interface adopted several years ago. The right way to
discriminate is using the reference ID and/or address.
The refclock_report() and other interface routines already report the
clock address. The same thing could be done for the syslog messages, but
to be consistent would require changing by my count about 400 syslog
messages in almost four dozen clock drivers and related code. Do we have
I'll fix the mode problem.
Mark Martinec wrote:
>>I diddled the atom driver to use the mode keyord value as PPSAPI mode
>>(decimal), which overrides flag2. Mark, have fun.
>Actually it is not ok (looking at ntp-dev-4.2.0a-20041212)
>The atom_start() passes a correct mode (obtained from the mode keyword)
>to the atom_ppsapi(), but then the atom_control() runs, recomputes
>the mode according to its own idea (flag2), and calls atom_ppsapi again,
>clobbering the already correctly configured ppsapi.
>Another thing: If I understand correctly, there could be multiple
>instances of atom refclocks, each given its own unit number.
>I'm running two of them (one on a parallel i/f, the other on DCD), yet
>the comments in the code like "int unit, /* unit number (not used) */"
>makes me a bit concerned, and the syslog messages are not clear to
>which instance they pertain.
>I would appreciate if the logged messages would report the atom
>unit number in question, e.g.
>@@ -256,3 +261,3 @@
>- "refclock_atom: time_pps_setparams failed: %m");
>+ "refclock_atom%d: time_pps_setparams failed: %m", unit);
> return (0);
>Btw, if some other refclock calls a (deprecated) pps_sample(),
>to which atom driver instance (unit number) is the sample fed?
More information about the hackers