[ntp:questions] Meinberg NTP monitor, silly question

David J Taylor david-taylor at blueyonder.delete-this-bit.and-this-part.co.uk.invalid
Tue Dec 22 09:15:43 UTC 2009


"Dave Hart" <davehart at gmail.com> wrote in message 
news:b6255676-5045-432e-9979-aca722a7d6f7 at u1g2000pre.googlegroups.com...
[]
> Yes, there is an issue with the messages coming from entirely separate
> components.  Moreover, as I have just said, the presence of user-mode
> PPS timestamps (replacing end-of-line timestamps on serial input) does
> not imply the lack of PPSAPI timestamps on the same port.  If I
> configure the NMEA driver to use PPSAPI directly, user-mode PPS
> timestamps remain active and functional from the perspective of the
> refclock serial support in ntpd on Windows.  The fact that higher-
> level code in the driver only uses those timestamps briefly during
> startup before switching to PPSAPI-provided timestamps is invisible to
> the code that logs the "using user-mode PPS" message.
>
> Similarly, the PPSAPI client code used by NMEA and atom has no way of
> knowing if the same port is also being used for serial timecode input,
> and if so, if the end of line timestamps have been tinkered.
>
> Finally, the PPSAPI client code in ntpd tends to follow the model of
> being quiet unless something goes wrong, so it's the absence of error
> messages with a PPSAPI-enabled driver (whether atom or another with
> PPSAPI integrated and enabled) that "logs" the success.
>
> Cheers,
> Dave Hart

Dave,

Thanks for that - the good news is that the "o" tally-code is sufficient. 
I've documented that here:

  http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html#kernel-check

I've also made a very brief and rather imperfect summary of the clear and 
most interesting points you made above.  Thanks to taking the time to 
spell that out in detail.  I may add that to the Web pages as well, if I 
may.

Cheers,
David 




More information about the questions mailing list