You are here: Part 2: Core Concepts > Receiving Data > DataReader QosPolicies > TIME_BASED_FILTER QosPolicy

TIME_BASED_FILTER QosPolicy

The TIME_BASED_FILTER QosPolicy allows you to specify that data should not be delivered more than once per specified period for data-instances of a DataReader—regardless of how fast DataWriters are publishing new DDS samples of the data-instance.

This QoS policy allows you to optimize resource usage (CPU and possibly network bandwidth) by only delivering the required amount of data to different DataReaders.

DataWriters may send data faster than needed by a DataReader. For example, a DataReader of sensor data that is displayed to a human operator in a GUI application does not need to receive data updates faster than a user can reasonably perceive changes in data values. This is often measure in tenths (0.1) of a second up to several seconds. However, a DataWriter of sensor information may have DataReaders that are processing the sensor information to control parts of the system and thus need new data updates in measures of hundredths (0.01) or thousandths (0.001) of a second.

With this QoS policy, different DataReaders can set their own time-based filters, so that data published faster than the period set by a DataReader will be dropped by the middleware and not delivered to the DataReader. Note that all filtering takes place on the reader side.

It includes the member in Table 23 . For the default and valid range, please refer to the API Reference HTML documentation.

Table 23 DDS_TimeBasedFilterQosPolicy

Type

Field Name

Description

DDS_Duration_t

minimum_separation

Minimum separation time between DDS samples of the same instance.

Must be <= DEADLINE::period

As seen in Accepting Data for DataReaders , it is inconsistent to set a DataReader’s minimum_separation longer than its DEADLINE QosPolicy period.

Figure 19 Accepting Data for DataReaders

DDS data samples for a DataReader can be filtered out using the TIME_BASED_FILTER QoS (minimum_separation). Once a DDS sample for an instance has been received, Connext DDS will accept but drop any new data samples for the same instance that arrives within the time specified by minimum_separation. After the minimum_separation, a new DDS sample that arrives is accepted and stored in the receive queue, and the timer starts again. If no DDS samples arrive by the DEADLINE, the REQUESTED_DEADLINE_MISSED status will be changed and Listeners called back if installed.

This QosPolicy allows a DataReader to subsample the data being published for a data instance by DataWriters. If a user application only needs new DDS samples for a data instance to be received at a specified period, then there is no need for Connext DDS to deliver data faster than that period. However, whether or not data being published by a DataWriter at a faster rate than set by the TIME_BASED_FILTER QoS is sent on the wire depends on several factors, including whether the DataReader is receiving the data reliably and if the data is being sent via multicast for multiple DataReaders.

For best effort data delivery, if the data type is unkeyed and the DataWriter has an infinite liveliness lease_duration (LIVELINESS QosPolicy), Connext DDS will only send as many packets to a DataReader as required by the TIME_BASED_FILTER, no matter how fast the DataWriter’s write() function is called.

For multicast data delivery to multiple DataReaders, the DataReader with the lowest TIME_BASED_FILTER minimum_separation determines the DataWriter's send rate. For example, if a DataWriter sends multicast to two DataReaders, one with minimum_separation of 2 seconds and one with minimum_separation of 1 second, the DataWriter will send every 1 second.

Other configurations (for example, when the DataWriter is reliable, or the data type is keyed, or the DataWriter has a finite liveliness lease_duration) must send all data published by the DataWriter. On reception, only the data that passes the TIME_BASED_FILTER will be stored in the DataReader’s receive queue. Extra data will be accepted but dropped. Note that filtering is only applied on ‘alive’ DDS samples (that is, DDS samples that have not been disposed/unregistered).

Example

The purpose of this QosPolicy is to prevent fast DataWriters from overwhelming a DataReader that cannot process the data at the rate the data is being published. In certain configurations, the number of packets sent by Connext DDS can also be reduced thus minimizing the consumption of network bandwidth.

You may want to change the minimum_separation between DDS data samples for one or more of the following reasons:

Properties

This QosPolicy can be modified at any time.

It only applies to DataReaders, so there are no restrictions for setting it compatibly on the DataWriter.

Related QosPolicies

Applicable Dds Entities

System Resource Considerations

Depending on the values of other QosPolicies such as RELIABILITY and TRANSPORT_MULTICAST, this policy may be able to decrease the usage of network bandwidth and CPU by preventing unneeded packets from being sent and processed.

© 2015 RTI