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:
1. Java initializes Apache NtpClient (uses NTPUDPClient.java)
2. Java sends a NTP/UDP message to chronyd to get PPS lock status.
3. 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?).
4. Java sends a chrony/UDP message to chronyd to get PPS estimated
error via REQ_TRACKING command.
- Pad the length of the request.
5. Java receives a UDP message from chronyd that includes the
current_correction, root_delay, and root_dispersion.
6. 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:
- Where do we read the PPS signal loss status? (What struct, what field?)
- Is there documentation (not a header file) that describes the fields
of UDP messages that chronyd can receive? Such as a block diagram similar
to:
https://archive.org/details/TIA-102_Series_Documents/TIA-102-BAAA-A_Project_25_FDMA_CAI/page/n35/mode/1up
Thanks again!
On Wed, Dec 15, 2021 at 12:33 AM Miroslav Lichvar <[email protected]>
wrote:
> 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 [email protected]
> with "unsubscribe" in the subject.
> For help email [email protected]
> with "help" in the subject.
> Trouble? Email [email protected].
>
>
