Thank you, Miroslav, that's quite helpful.
I'm a little confused about the protocol. We'd like to get both NTP and 1PPS statuses from Java without using ProcessBuilder (execve). This means we cannot run chronyc directly; sending commands to chronyd via local sockets would be fine.
When you mention "chronyc commands", do you mean we can send UDP messages to chronyd that are equivalent to the chronyc commands (so we needn't execute the chronyc binary)?
When you wrote about "chrony's own protocol", does that mean we can't use a Java-based NTP client that sends UDP messages to extract the information we need?
Here's my understanding of how this could work:
- Java initializes Apache NtpClient (uses NTPUDPClient.java)
- Java sends a NTP/UDP message to chronyd to get PPS lock status.
- Java sends a NTP/UDP message to chronyd to get PPS signal loss status.
- Requires configuring the polling interval to 1 second (e.g., /etc/chronyd.conf?).
- Java sends a chrony/UDP message to chronyd to get PPS estimated error via REQ_TRACKING command.
- Pad the length of the request.
- Java receives a UDP message from chronyd that includes the current_correction, root_delay, and root_dispersion.
- Java computes the threshold using:
- fabs(current_correction) + root_delay / 2 + root_dispersion
Is that about right? If not, where is my understanding incorrect?
A few follow-up questions:
Thanks again!
On Tue, Dec 14, 2021 at 11:13:34AM -0800, Thangalin wrote:
> 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),
This part won't work with chrony. It doesn't use the kernel PPS
discipine. But you can monitor the PPS refclock as any other source
with chronyc commands.
> 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
These should be ok.
> - 1PPS signal loss can be detected immediately (e.g., upon querying its
> status).
There would be a delay of one polling interval if you were monitoring
the reference time in the tracking command or reachability in the
sources command. You can set the polling interval to 1 second.
> 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.
Look at the candm.h file in the chrony source code. It's not NTP. It's
chrony's own protocol. You would send chronyd a request with the
REQ_TRACKING command and process response containing RPY_Tracking. You
would check if the reference time is not too old (e.g. more than 5
seconds) and check if
fabs(current_correction) + root_delay / 2 + root_dispersion
is not larger than your threshold of 5 or 10 microseconds.
Note that you need to pad the request to the length of the response.
If you capture few requests from chronyc, you will see what fields
need to be set.
--
Miroslav Lichvar
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.