Hi there, A Java application uses a ProcessBuilder to execute the ntpq and ntptime commands to determine the following pieces of information:
- 1PPS lock status - 1PPS connection status - Estimated error Calling execve is an expensive operation and I'd like to swap it for a relatively lightweight UDP call. Java libraries can send/receive NTP messages over UDP, such as Apache Commons Net <https://commons.apache.org/proper/commons-net/>, JavaSntpClient <https://support.ntp.org/bin/view/Support/JavaSntpClient>, and spf4j <https://github.com/zolyfarkas/spf4j/blob/master/spf4j-core/src/main/java/org/spf4j/net/SntpClient.java>'s client. For example, when 1PPS is not locked, the ntpq command returns: remote refid st t when poll reach delay offset jitter ============================================================================== *127.127.1.0 .LOCL. 2 l 4 16 377 0.000 0.000 0.002 127.127.22.1 .PPS. 0 l - 8 0 0.000 0.000 0.000 When 1PPS is locked, it returns (fudged IP): remote refid st t when poll reach delay offset jitter ============================================================================== *192.168.66.196 129.6.15.28 2 u 12 16 377 0.238 +0.639 0.027 127.127.1.0 .LOCL. 2 l 19h 16 0 0.000 +0.000 0.000 o127.127.22.1 .PPS. 0 l 1 16 377 0.000 -0.001 0.002 The output from the commands can be parsed and relayed to the rest of the Java application. Similarly, when the 1PPS signal has been lost (e.g., GPIO cable unplugged), the ntptime command returns: ntp_gettime() returns code 5 (ERROR) maximum error 206000 us, estimated error 0 us, status 0x2007 (PLL,PPSFREQ,PPSTIME,NANO), Note the lack of *PPSSIGNAL*, which is present when the GPIO port is carrying a signal: ntp_adjtime() returns code 0 (OK) maximum error 206000 us, *estimated error 1 us*, status 0x2107 (PLL,PPSFREQ,PPSTIME,*PPSSIGNAL*,NANO), When the estimated error is between 5 and 10 us, we issue a warning. When greater than 10 us, we take other actions. Again, this information is parsed from by reading from standard output, which I'd like to avoid. >From the documentation/faq, the chrony daemon looks like it can provide all this information. I'd like to confirm that: - we can replace ntpd (ntpq/ntptime) with chronyd; - chronyd can return the requisite pieces of information; - it is possible to use a Java-based NTP client to obtain the data we seek; and - 1PPS signal loss can be detected immediately (e.g., upon querying its status). Additional pointers to information on the NTP UDP messages with respect to chrony that documents the fields we'd need to extract would be most appreciated. Thank you!