[ntp:questions] Ramifications of bug 1999 resolution: "Remove PMOTG output senten ce from Type-20 driver"
darren.long at mac.com
Fri Sep 30 16:44:35 UTC 2011
On 30 Sep 2011, at 16:38, Dave Hart wrote:
> On Fri, Sep 30, 2011 at 12:39, Long, Darren wrote:
>> I've just noticed bug 1999, "Remove PMOTG output sentence from Type-20
>> 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
> 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.
OK. I'm convinced. Monitoring the health of the NTP server is mostly out of scope of my work anyway, its just that I realised that I could do it, so I coded for it. Now I can make it someone else's problem :P
>> 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.
Fair enough. I can see the need to purge the cruft from the reference implementation as far as possible.
Thanks for the responses,
More information about the questions