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. Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
