When dealing with system clock adjustments (manually or due to clock server synchronization), my subscriber drops all samples once the system has been set back into the past.
This seems to be due to DataReaderHistory::received_change_keep_last / DataReaderHistory::completed_change_keep_last comparing all the incoming samples' sourceTimestamp (which will be a timestamp in the past once the clock has been changed) to the first change's, leading to all samples to be dropped:
CacheChange_t* first_change = instance_changes.at(0);
if (change->sourceTimestamp >= first_change->sourceTimestamp)
{
// As the instance is ordered by source timestamp, we can always remove the first one.
ret_value = remove_change_sub(first_change);
}
else
{
// Received change is older than oldest, and should be discarded
return true;
}
If I remove the if and simply drop the first sample everything seems to work unaffected from the system clock adjustments.
Note that I would expect the current fast dds behaviour if DestinationOrderQosPolicy were implemented (which it is not) and set to BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS. However, according to the manual should be BY_RECEPTION_TIMESTAMP_DESTINATIONORDER_QOS .
Note that I have created a pull request for additional observations when the system clock is adjusted (PR #5018).
This might be related to #4850.
Current behavior
Samples get dropped when publisher's system clock is set into the past.
Steps to reproduce
Set back system clock after disabling automatic synchronization via NTP.
Is there an already existing issue for this?
Expected behavior
When dealing with system clock adjustments (manually or due to clock server synchronization), my subscriber drops all samples once the system has been set back into the past. This seems to be due to DataReaderHistory::received_change_keep_last / DataReaderHistory::completed_change_keep_last comparing all the incoming samples' sourceTimestamp (which will be a timestamp in the past once the clock has been changed) to the first change's, leading to all samples to be dropped:
If I remove the if and simply drop the first sample everything seems to work unaffected from the system clock adjustments.
Note that I would expect the current fast dds behaviour if DestinationOrderQosPolicy were implemented (which it is not) and set to BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS. However, according to the manual should be BY_RECEPTION_TIMESTAMP_DESTINATIONORDER_QOS .
Note that I have created a pull request for additional observations when the system clock is adjusted (PR #5018).
This might be related to #4850.
Current behavior
Samples get dropped when publisher's system clock is set into the past.
Steps to reproduce
Set back system clock after disabling automatic synchronization via NTP.
Fast DDS version/commit
2.14.2
Platform/Architecture
Ubuntu Focal 20.04 amd64
Transport layer
Shared Memory Transport (SHM)
Additional context
No response
XML configuration file
No response
Relevant log output
No response
Network traffic capture
No response