[ntp:questions] Meinberg NTP monitor, silly question

Dave Hart davehart at gmail.com
Mon Dec 21 17:25:34 UTC 2009


> "Dave Hart" <davehart at gmail.com> wrote in message
> > The fact that the NMEA refclock
> > is using user-mode PPS timestamps does not imply the PPS/atom driver
> > is not.

I should have said the fact that a message about user-mode PPS is
logged does not imply PPSAPI is not available or even being used.  You
could see the user-mode PPS message (which is only seen with the
Windows ntpd, for those who are baffled by this user-mode PPS
discussion) during startup of NMEA configured to use PPSAPI directly
(which implies not configuring PPS/atom as a separate source).  The
user-mode PPS message is coming from the common reference clock serial
support code, and occurs if a PPS signal is detected on the DCD line
of a serial port being read by a refclock.  In that case, the
timestamp of each PPS event is saved and replaces the normal end-of-
line timestamp of the following line of serial input read by the clock
driver, which is the reason you must configure only one sentence (line
of serial input) per second for the user-mode PPS hack to work as
intended.

On Dec 21, 16:16 UTC, "David J Taylor" wrote:
> That's most helpful.  So just to be sure:  if the "o" appears as the
> tally-code, the system /must/ be using kernel mode timestamps.  Yes?

Yes.

> Could the use of kernel-mode be logged, as having the "user-mode" message
> causes confusion.  Or is it not that simple now the components are
> separate?

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




More information about the questions mailing list