Re: [chrony-users] Get time and pps status from Java |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
- To: chrony-users@xxxxxxxxxxxxxxxxxxxx
- Subject: Re: [chrony-users] Get time and pps status from Java
- From: Miroslav Lichvar <mlichvar@xxxxxxxxxx>
- Date: Wed, 15 Dec 2021 09:32:46 +0100
- Authentication-results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mlichvar@xxxxxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1639557171; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lX5VZeK/CF7B5JkYbL6Ag8j9/l51mN4rlX+wtWmpBJc=; b=SqGOPLAWN6YNYSIjBfx2trg2aVoiA05dcRc87HyPGtla5PeDu1nYcTmDEHXPgoi8598+Gw 4CtZJ2ac24tWa798ELQuik9oTqwAKxeGHqr+/1lyvLnQq05W5MC9ImtBBwtwBSNg7vf58T 0xYAERmg0H+/Sa3o2QvOjGU5HCGBpHk=
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.