Re: [chrony-users] Integrating SOCK and PPS refclocks using custom application |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
- To: chrony-users@xxxxxxxxxxxxxxxxxxxx
- Subject: Re: [chrony-users] Integrating SOCK and PPS refclocks using custom application
- From: Miroslav Lichvar <mlichvar@xxxxxxxxxx>
- Date: Thu, 12 Sep 2024 09:55:17 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1726127723; 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=8mbsr0CzbfmMNOhPAxu0CbepkasTZ4Vn8+9ph4klDs8=; b=HsoJHkXBSWF/ZvH4OUzS8tqHJKYobgQg1Xu9ItfMP8iZtEHJ6slcmhOCF0rvlzv9RThTVV qM8oe6pi9czeP+piJHWix/hkcA/m+dJH8P/BZ1ZMe4T2SkXLDVTG1aT0s2DII07W0w0oxE GNNqqngViODLwIf+e5lHZ8T56kWPCLw=
On Wed, Sep 11, 2024 at 08:48:16PM -0700, Stephen Oneto wrote:
> What I (probably incorrectly) infer from this statement is that the PPS
> refclock will take the system time at the point of PPS assertion and the
> SOCK refclock is responsible for telling chrony what UTC second that PPS
> signal is associated with.
It is, but not directly. chronyd compares the offsets provided by the
two refclocks. It needs to work even when the system clock is not
synchronized yet.
> If such is the case, does this mean I can simply send the GPS fix time
> (i.e. the UTC second that it will be at the next PPS assertion) once per
> second over the socket in advance of the PPS assertion while the PPS
> refclock is locked to this SOCK refclock? Would I just leave the offset as
> 0 since chrony would be using the PPS timestamp generated by the PPS
> refclock as the time to compare the fix time with?
The SOCK sample time should be the system time when the message
containing the fix time is received and the offset should be the
difference between the fix time and sample time. You say UTC second at
the next PPS assertion. I don't know if that is specific to your
receiver. Usually the message follows the pulse, at least in NMEA and
similar. If the message comes earlier, the offset option of the SOCK
refclock would need to be negative.
I'd suggest to start with the SOCK refclock alone and only when that
works well (within few tens of milliseconds?), add the PPS refclock.
--
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.