[ntp:hackers] Re: The ATOM Driver.

David L. Mills mills at udel.edu
Sun Feb 19 04:12:11 UTC 2006


John,

I don't buy it. The prefer peer gizmo is already used to link the atom 
driver to another serial driver or external server. True, only one atom 
driver is supported in this way and you might want more than one.

While the PPS defines the on-time epoch, The serial timecode must be 
within a half second of that or the driver would come up in the wrong 
second. My suggestion was to open up the min distance to allow a wider 
tolerance for that.

I'm really, really tired of this discussion, which has come up so many 
times. My motive was to simplify the code, mitigate large differences 
between the serial code and PPS (which occasionally happens in my GPS 
reeivers), have a more transparent monitoring of the serial offset and 
make it easier to add other similar drivers. You write the drivers and 
not me. If it's your choice to do it your way, I'm off the boat.

By the way, I understand the serial problem is a sawtooth with a 
relatively long period. You can reduce or eliminate the sawtooth 
amplitude using a transverse filter such as the refclock_irig.c 
IRIG_SUCKS filter used to reduce the codec sawtooth.

Dave

John Hay wrote:

> Dave,
>
>> Scrunching the atom code to the daemon would be very awkward. The design
>> philosophy has been to banish things like serial and parallel ports to
>> specialized drivers. The PPS signal is special in that it needs another
>> driver or server to number the seconds, watch for errors and so forth.
>> Also, the PPS signal itself has some degree of fragility, as it usually
>> needs a separate cable, level converter and Wye connector contraption.
>> In the current design the mitigation algorithms nicely solve the error
>> and fallback problem.
>>
>> I don't understand your question. I have not asked the GPS drivers to
>> change to use the atoms; I have suggested to remove the PPS code
>> entirely and let the atom driver do the work. The one thing the drivers
>> would need to change is to increase the root distance to something a
>> little more than the peak-peak timecode jitter. That would be a good
>> thing and avoid lying to the mitigation algorithms.
>
>
> You look at it from the atom driver point of view and some of us from
> some other driver point of view. :-)
>
> Some of the time sources use the serial stream and PPS signal as a unit,
> so much so that one cannot really work only with the serial stream (or
> whatever way they send the date/time data). They work much the same as
> the radio stations that will broadcast "When you hear the beep it will
> be 7 o'clock..... beep". So without the beep there is no meaning to
> whatever was said before that.
>
> So to handle this kind of thing, maybe one should be able to link a
> specific instance of the atom driver to a specific instance of some
> other driver, so that they work together. Maybe somewhat like one
> could do with the old xntp version 3 code. There you could actually
> call hooks in the atom driver from your own driver.
>
> John




More information about the hackers mailing list