48.4 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 48.5 DDS_TimeBasedFilterQosPolicy. For the default and valid range, please refer to the API Reference HTML documentation.

Table 48.5 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 Figure 48.1: Accepting Data for DataReaders , it is inconsistent to set a DataReader’s minimum_separation longer than its 47.7 DEADLINE QosPolicy period.

Figure 48.1: 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 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 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 (47.15 LIVELINESS QosPolicy), Connext 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).

48.4.1 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 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:

  • The DataReader is connected to the network via a low-bandwidth connection that is unable to sustain the amount of traffic generated by the matched DataWriter(s).
  • The rate at which the matched DataWriter(s) can generate DDS samples is faster than the rate at which the DataReader can process them. Or faster than needed by the DataReader. For example, a graphical user interface seldom needs to be updated faster than 30 times a second, even if new data values are available much faster.
  • The resource limits of the DataReader are constrained relative to the number of DDS samples that could be generated by the matched DataWriter(s). Too many packets coming at once will cause them to be exhausted before the DataReader has time to process them.

48.4.2 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.

48.4.3 Related QosPolicies

48.4.4 Applicable DDS Entities

48.4.5 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.