Hi Stephen and Ritchie,
We have a program to receive the frames sent by openPDC and insert it into the MySQL database for other application. However, we found the frame rate of data stream reduced rapidly from 30 frames/sec to 0.5 frames/sec. The main reason of this phenomenon is the latency of data is lager time lag threshold.
The latency of output stream and lag setting are shown below.
My questions are:
Is this latency normal? It was around 1000ms in the last year and it is 2000ms now.
Anything we could do to reduce the latency of output stream?
Best regards,
Aaron
Hi Aaron,
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.
Thanks,
Stephen
1 Like
