[ntp:questions] Ramifications of bug 1999 resolution: "Remove PMOTG output senten ce from Type-20 driver"

Dave Hart hart at ntp.org
Fri Sep 30 15:38:33 UTC 2011

On Fri, Sep 30, 2011 at 12:39, Long, Darren wrote:
> I've just noticed bug 1999, "Remove PMOTG output sentence from Type-20
> driver".
> I've found a use for the PMOTG message output, which I've started to use as
> a heartbeat from ntpd in my bespoke nav software which forwards RMC messages
> to the ntpd via a virtual serial port on Windows. I find this to be a useful
> mechanism to determine if the panic threshold has been exceeded and ntpd has
> aborted, as my software can generate an alert to the user that they should
> set the system clock to UTC, at least within the tolerance of the panic
> threshold.

That's one way to detect ntpd is dead, granted, but it is far from the
only way.  You could use the Windows service control API to check the
status of the NTP service, or even spawn a "sc query ntp" and scrape
its output:

STATE              : 4  RUNNING

You could send a client mode NTP packet to localhost:123 and call it
dead if you don't receive a server mode reply.

> Whilst I agree that ntpd probably doesn't need to send this by default, and
> also have no imminent concern as we're using the new stable release 4.2.6p4
> which still sends the PMOTG messages at the poll interval, I'd like to know
> that ntpd can still be built with this mechanism enabled for refclock 20 in
> future versions.
> I note that NMEA_WRITE_SUPPORT is defined in refclock_nmea.c and wonder if
> instead of the option being buried there, it could instead be enabled more
> conveniently (for Windows ports and regular builds) at build time without
> resorting to patching code.

For most systems, it could be exposed via a configure option, but the
Windows port doesn't have any such build-time option mechanism to
leverage.  Which means if the $PMOTG polling were preserved for your
use, it would have to a runtime configuration option, perhaps taking
advantage of the recent growth of the "mode" option to refclocks from
8 bits to 32 bits.

> I also appreciate that this is a real corner case and that I'm a little fish
> in a big pond, so I could understand if there was no desire to accomodate my
> needs, but it would be good to know what the future holds in this regard
> before I pack and ship my nav sw.

For as long as I've been using the NMEA driver in ntpd, I've wanted to
get rid of the $PMOTG polling, convinced that the GPS(es) that needed
it have long fallen out of service.  It has long seemed like needless
complication of the driver code for a narrow corner case.

Repurposing it as a convenient means to detect ntpd stopping is
clever, but as you note it's a corner case.  Given there are plenty of
options for detecting ntpd stopping, I would prefer you find another
means to achieve your goal.  My preference would be to actually rip
the write support out of refclock_nmea.c entirely to simplify the
code, rather than leave if #ifdef'd out.

Dave Hart

More information about the questions mailing list