Relax requirement on timestamp consistency checker #2931
Conversation
Don't account for inconsistent timestamps (e.g due to disconnection or hardware error) as long as there is at least one subdevice still reporting current data. Use valid timestamps only for obtaining the average timestamp used as envelope in broadcast state messages. Also, throttle the inconsistency error message to avoid flooding logs.
PeterBowman
had a problem deploying
to
code-analysis
GitHub Actions
Failure
PeterBowman
temporarily deployed
to
code-analysis
GitHub Actions
Inactive
PeterBowman
had a problem deploying
to
code-analysis
GitHub Actions
Failure
|
On a second thought, I might want to keep publishing state even if the last read happened a while ago (e.g. some or all subdevices are currently disconnected). The main question here is: what is the desired behavior if two nodes differ significantly in the timestamp of the last successful acquisition? How is the average time used as port envelope supposed to be obtained in this case? Edit: I believe remotecontrolboard could benefit from a thorough review regarding timestamp handling. According to the contract of IPreciselyTimed, it is the last acquisition the one we are interested in, so perhaps the stale ones (corresponding to inactive subdevices) can be ignored. Besides, maybe the NWS should fill a new field of timestamps to be later read by |
|
I have proposed a different approach at #2939. |
Don't account for inconsistent timestamps (e.g due to disconnection or hardware error) as long as there is at least one subdevice still reporting current data. Use valid timestamps only for obtaining the average timestamp used as envelope in broadcast state messages.
Also, throttle the inconsistency error message to avoid flooding logs.