This is an automated email from git. It was generated because a ref change was pushed to the "chrony/chrony.git" repository.
The branch, master has been updated via e949e1d9914f80160972379f9f9927356d9e8581 (commit) via c8649ccb7e5d88749d588fd55d3202c5bed84eec (commit) via 39ff7ceecaa84fdd24e9ef8507f17384174222a5 (commit) via 06945d927b84d00dbd9e11301ae7a28b4db5f048 (commit) via caf82b1a45c2d2ee6d22cb0a1edc2b2e2be1a0ff (commit) via f99b2f633b989ba7b8edc500d2ea8985979a8de7 (commit) via 6270a3eb7cf8e35673cb19ea8e12bd6c8b15ede2 (commit) via 1daa40a2f759df30a7afe086c9f001d99fdd14a3 (commit) via a1406eded39e3f607f5fbc5fa3a5f8720a1e5bc1 (commit) from 1eb8994c0052ac746f5084ff375fcd9896b93452 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit e949e1d9914f80160972379f9f9927356d9e8581 Author: Miroslav Lichvar <mlich...@redhat.com> Date: Thu Mar 2 11:29:49 2023 +0100 test: update description of 106-refclock commit c8649ccb7e5d88749d588fd55d3202c5bed84eec Author: Miroslav Lichvar <mlich...@redhat.com> Date: Wed Mar 1 16:39:35 2023 +0100 refclock_phc: support multiple extpps refclocks on one PHC The Linux kernel (as of 6.2) has a shared queue of external timestamps for all descriptors of the same PHC. If multiple refclocks using the same PHC and the same or different channels were specified, some refclocks didn't receive any or most of their timestamps, depending on the rate and timing of the events (with the previous commit avoiding blocking reads). Track extpps-enabled refclocks in an array. Add PHC index to the PHC instance. When a timestamp is read from the descriptor, provide it to all refclocks that have the same PHC index and a channel matching the event. Make sure the timestamp is different from the previous one in case the kernel will be improved to duplicate the timestamps for different descriptors. Reported-by: Matt Corallo <ntp-li...@mattcorallo.com> commit 39ff7ceecaa84fdd24e9ef8507f17384174222a5 Author: Miroslav Lichvar <mlich...@redhat.com> Date: Wed Mar 1 14:41:34 2023 +0100 sys_linux: avoid blocking in reading of external PHC timestamp The kernel has a common queue for all readers of a PHC device. With multiple PHC refclocks using the same device some reads blocked. PHC devices don't seem to support non-blocking reads. Use poll() to check if a timestamp is available before reading from the descriptor. commit 06945d927b84d00dbd9e11301ae7a28b4db5f048 Author: Miroslav Lichvar <mlich...@redhat.com> Date: Wed Mar 1 16:02:50 2023 +0100 test: add array unit test commit caf82b1a45c2d2ee6d22cb0a1edc2b2e2be1a0ff Author: Miroslav Lichvar <mlich...@redhat.com> Date: Wed Mar 1 16:02:16 2023 +0100 array: add function for removing elements commit f99b2f633b989ba7b8edc500d2ea8985979a8de7 Author: Miroslav Lichvar <mlich...@redhat.com> Date: Mon Feb 27 15:29:44 2023 +0100 ntp: count missing samples when waiting for NTS-KE Count missing samples for the median filter when NAU_PrepareRequestAuth() is failing. Fixes: 4234732b0883 ("ntp: rework filter option to count missing samples") commit 6270a3eb7cf8e35673cb19ea8e12bd6c8b15ede2 Author: Miroslav Lichvar <mlich...@redhat.com> Date: Mon Feb 27 15:00:50 2023 +0100 ntp: don't adjust poll interval when waiting for NTS-KE Don't adjust the NTP polling interval and decrement the burst count when NAU_PrepareRequestAuth() fails (e.g. no NTS-KE response received yet, network being down, or the server refusing connections), same as if an NTP request could not be sent. Rely on the rate limiting implemented in the NTS code. commit 1daa40a2f759df30a7afe086c9f001d99fdd14a3 Author: Miroslav Lichvar <mlich...@redhat.com> Date: Thu Feb 23 13:10:11 2023 +0100 nts: use shorter NTS-KE retry interval when network is down When chronyd configured with an NTS source not specified as offline and resolvable without network was started before the network was up, it was using an unnecessarily long NTS-KE retry interval, same as if the server was refusing the connections. When the network is down, the connect() call made from NKC_Start() on the non-blocking TCP socket should fail with a different error than EINPROGRESS and cause NKC_Start() to return with failure. Add a constant 2-second retry interval (matching default iburst) for this case. commit a1406eded39e3f607f5fbc5fa3a5f8720a1e5bc1 Author: Miroslav Lichvar <mlich...@redhat.com> Date: Thu Feb 23 14:58:29 2023 +0100 nts: destroy NTS-KE client right after failed start When NKC_Start() fails (e.g. due to unreachable network), don't wait for the next poll to destroy the client and another poll to create and start it again. ----------------------------------------------------------------------- Summary of changes: array.c | 15 +++++++ array.h | 3 ++ ntp_core.c | 5 +-- nts_ntp_client.c | 17 +++++--- refclock_phc.c | 74 +++++++++++++++++++++++++++------ sys_linux.c | 11 +++++ test/simulation/106-refclock | 2 +- test/unit/array.c | 97 ++++++++++++++++++++++++++++++++++++++++++++ 8 files changed, 202 insertions(+), 22 deletions(-) create mode 100644 test/unit/array.c hooks/post-receive -- chrony/chrony.git -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.