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