ptpclock: Allow at least 100ms delay between Sync/Follow_Up and Delay_Req/Delay_Resp messages

It doesn't matter for measurement purposes whether receiving them takes
a while and various PTP servers are not prioritizing to send them,
causing them to be dropped unnecessarily and preventing proper
synchronization with such servers.

This is especially a problem if the RTTs in the network are very low
compared to the additional delay imposed by the server.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2161>
This commit is contained in:
Sebastian Dröge 2022-04-12 19:22:51 +03:00 committed by Seungha Yang
parent 83ba83924a
commit 416e16aefd

View file

@ -1106,15 +1106,20 @@ update_ptp_time (PtpDomainData * domain, PtpPendingSync * sync)
* we can get here without a delay response too. The tolerance on
* accepting follow-up after a sync is high, because a PTP server
* doesn't have to prioritise sending FOLLOW_UP - its purpose is
* just to give us the accurate timestamp of the preceding SYNC */
* just to give us the accurate timestamp of the preceding SYNC.
*
* For that reason also allow at least 100ms delay in case of delays smaller
* than 5ms. */
if (sync->follow_up_recv_time_local != GST_CLOCK_TIME_NONE
&& sync->follow_up_recv_time_local >
sync->sync_recv_time_local + 20 * domain->mean_path_delay) {
sync->sync_recv_time_local + MAX (100 * GST_MSECOND,
20 * domain->mean_path_delay)) {
GstClockTimeDiff delay =
sync->follow_up_recv_time_local - sync->sync_recv_time_local;
GST_WARNING ("Sync-follow-up delay for domain %u too big: %"
GST_STIME_FORMAT " > 20 * %" GST_TIME_FORMAT, domain->domain,
GST_STIME_ARGS (delay), GST_TIME_ARGS (domain->mean_path_delay));
GST_STIME_FORMAT " > MAX(100ms, 20 * %" GST_TIME_FORMAT ")",
domain->domain, GST_STIME_ARGS (delay),
GST_TIME_ARGS (domain->mean_path_delay));
synced = FALSE;
gst_clock_get_calibration (GST_CLOCK_CAST (domain->domain_clock),
&internal_time, &external_time, &rate_num, &rate_den);
@ -1374,13 +1379,17 @@ update_mean_path_delay (PtpDomainData * domain, PtpPendingSync * sync)
#ifdef USE_MEASUREMENT_FILTERING
/* The tolerance on accepting follow-up after a sync is high, because
* a PTP server doesn't have to prioritise sending FOLLOW_UP - its purpose is
* just to give us the accurate timestamp of the preceding SYNC */
* just to give us the accurate timestamp of the preceding SYNC.
*
* For that reason also allow at least 100ms delay in case of delays smaller
* than 5ms. */
if (sync->follow_up_recv_time_local != GST_CLOCK_TIME_NONE &&
domain->mean_path_delay != 0
&& sync->follow_up_recv_time_local >
sync->sync_recv_time_local + 20 * domain->mean_path_delay) {
MAX (100 * GST_MSECOND,
sync->sync_recv_time_local + 20 * domain->mean_path_delay)) {
GST_WARNING ("Sync-follow-up delay for domain %u too big: %" GST_TIME_FORMAT
" > 20 * %" GST_TIME_FORMAT, domain->domain,
" > MAX(100ms, 20 * %" GST_TIME_FORMAT ")", domain->domain,
GST_TIME_ARGS (sync->follow_up_recv_time_local -
sync->sync_recv_time_local),
GST_TIME_ARGS (domain->mean_path_delay));
@ -1406,11 +1415,14 @@ update_mean_path_delay (PtpDomainData * domain, PtpPendingSync * sync)
* hope for, but some PTP systems don't prioritise sending DELAY_RESP,
* but they must still have placed an accurate reception timestamp.
* That means we should be quite tolerant about late DELAY_RESP, and
* mostly rely on filtering out jumps in the mean-path-delay elsewhere */
if (delay_req_delay > 20 * domain->mean_path_delay) {
* mostly rely on filtering out jumps in the mean-path-delay elsewhere.
*
* For that reason also allow at least 100ms delay in case of delays smaller
* than 5ms. */
if (delay_req_delay > MAX (100 * GST_MSECOND, 20 * domain->mean_path_delay)) {
GST_WARNING ("Delay-request-response delay for domain %u too big: %"
GST_TIME_FORMAT " > 20 * %" GST_TIME_FORMAT, domain->domain,
GST_TIME_ARGS (delay_req_delay),
GST_TIME_FORMAT " > MAX(100ms, 20 * %" GST_TIME_FORMAT ")",
domain->domain, GST_TIME_ARGS (delay_req_delay),
GST_TIME_ARGS (domain->mean_path_delay));
ret = FALSE;
goto out;