My first positive structural change to NTP
Stromeko at nexgo.de
Sun Jun 26 15:26:08 UTC 2016
Hal Murray writes:
> Stromeko at 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.
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Waldorf MIDI Implementation & additional documentation:
More information about the devel