[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 
a volunteer?

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 @@
>                msyslog(LOG_ERR,
>-                   "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?
>  Mark

More information about the hackers mailing list