Hal Murray writes: > strom...@nexgo.de said: >> I think that's still perpetuating a mistake. This whole business of having >> to specify two servers (or refclocks) for the same thing should go away. > > There is a fundamental issue. With a PPS, there really are two sources of > time. Internally, ntpd needs two different handles so you can see both sets > of info on ntpq -peers and clockstats.
I think that at least initially, the ATOM driver was supposed to only deliver a frequency to calibrate the other time sources to. That is the only case where it still makes sense to have a separate refclock entry for, IMHO. But for ntpd that clock can't be used directly since it only provides relaztive time information. > Normally, each PPS has an associated serial stream. It would be good if > there were a clean way to specify that rather than using the prefer kludge. That's a result of how getting the clock information into the ntpd has been handled and which facilities are used to support it. But fundamentally, all ntpd cares about is that it gets a high resolution timestamp in kernel time for some piece of absolute time information from the refclock. If a refclock driver provides hardware timestamped memory buffers to ntpd, it wouldn't need to know or care about the implementation detail that the timestamp was delivered on a different line than the bits in hte memory buffer. > Is there a udev equivalent on other OSes? I guess anything that supports plug&play has something like it. But if not, a symbolic link or device creation script serves the same purpose. With udev you can automate the device creation and removal and can do it at runtime and not just at boot, which is more convenient, though. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
