diff --git a/subprojects/gstreamer/libs/gst/net/gstptpclock.c b/subprojects/gstreamer/libs/gst/net/gstptpclock.c index eb7e5bd70a..286bba6efb 100644 --- a/subprojects/gstreamer/libs/gst/net/gstptpclock.c +++ b/subprojects/gstreamer/libs/gst/net/gstptpclock.c @@ -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;