I don’t believe the latency is your problem here. With a lag time of 2 seconds, it’s perfectly reasonable for frames to be sent out 2 seconds after the frame timestamp. Rather, that’s just what happens when the concentrator doesn’t receive all your data within 2 seconds of the frame timestamp.
Honestly, the statistics at the top of the list are more indicative of what’s going on than anything. It looks like the vast majority of your measurements are not being discarded, but rather downsampled. This is almost certainly related to the fact that literally all of the measurements from the device are also being sorted by arrival. This means that the concentrator is disregarding the timestamp from the device and instead using the time that the measurements arrived to figure out which frame they belong to.
At this point, it’s worth noting that sorting by arrival occurs when the device is reporting the
BadTime state flag and the option is enabled in the concentrator to allow sorting by arrival. You may want to investigate the source device to determine why the data is being flagged with
BadTime. If you disable the
Allow Sorts By Arrival setting on your concentrator configuration, your concentrator will discard the measurements instead of attempting to sort them by arrival. To instead tell the concentrator to ignore the
BadTime flag altogether, you can enable the
Ignore Bad Timestamps setting.
Digging a bit deeper, it seems like all your incoming measurements are outside the reasonability window defined by the
Lead Time setting. When all incoming measurement timestamps are unreasonable, the concentrator will not update the value for
RealTime using the incoming measurements’ timestamps. Instead, the current value for
RealTime will only be updated periodically whenever it falls outside the reasonability window. In your case, this means the
RealTime timestamp is being updated to the value reported by the local clock every 2 seconds, or approximately 5 times in every statistic reporting interval. That’s why only 6 frames were published in the statistic reporting window captured by your screenshot. In other words, there were only 6 distinct timestamps in that 10-second window assigned to your incoming measurements based on the logic for updating
RealTime and sorting by arrival.
If you can’t trust the timestamps coming from your input device, you may want to consider enabling the
Use Local Clock As Real-time setting on your concentrator configuration. This will allow the concentrator to keep
RealTime up to date with the PDC’s local clock instead of using the device’s faulty timestamps. If instead you’d like to use the device’s timestamp regardless of reasonability, disable the
Perform Timestamp Reasonability Check setting.