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 >> 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.
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, Darren _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
