My first positive structural change to NTP
Stromeko at nexgo.de
Sun Jun 26 15:57:16 UTC 2016
Eric S. Raymond writes:
> The reason I disagree is I think you're overfocusing on the fact that
> both refclocks are the same physical device and underfocusing on the
> fact that they're two different data channels, possibly with different
> fudges and modes.
No, it's exactly my contention that this is an implementation detail
that ntpd doesn't really need to care about. Besides, there are
refclocks that use multiple sources of time and can optionally deliver
either the combination of those sources or information on each source
seperately. So ntpd conceivably needs to deal with multiple references
via the same data channel or the the same reference via multiple data
channels. The only thing it should care about is whether that reference
is an absolute or relative time source.
> *Because* fudges and modes may differ, I think it is right for the
> configuration syntax to be data-channel-focused rather than
> device-focused. Doing it the other way could land you in a spot
> where you want to specify differing per-channel behavior but cannot.
Ideally that part of the setup should be moved to a separate
per-refclock configuration file. That file could then specify which
data channels are used and what their relations are, including any
"fudges" that relate to this specific instance.
> The prefer keyword may be a separate issue, and dispensable. But
> I think that is a different, more specific argument.
The prefer keyword should get it's original meaning back. The
association of an absolute refclock with a relative one in the sense of
"these pieces of time information are related to this stream of PPS
timestamps" should be a separate keyword.
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf Blofeld:
More information about the devel