-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Non slewing time adjustments #203
Comments
Discussion: Changing the sequence ID of the MDIB is the only way of managing the issues resulting from non-slewing adjustments. This will result in a requirement and guidance for how to reduce the likelihood for non-slewing adjustments. |
@d-gregorczyk and @AnnaFeiler, here is a first sketch. If it looks good (enough) I'll make a PR along these lines: 1- The Manufacturer of a SOMDS Participant should configure its grouped CT Time Client Actor to give priority to system clock adjustments that are slewing (over stepping adjustments). Note: If possible, the priority of slewing adjustments should start once a CT Time Client Actor has acquired synchronization after a system (re)start. 2- The SOMDS Provider shall set its MDIB SequenceId to a new value when it detects a stepping system clock adjustment with a step greater than 10 seconds. Note: The SOMDS Consumer should consider the possibility of a stepping clock adjustment having occurred at the SOMDS Provider when it receives a changed value in the SOMDS Provider's MDIB SequenceId. This text may fit in 1:C.2.5 Scenarios, which already provides guidance and requirements on time synchronization. |
I can't comment on 1, not enough expertise. :-/ When as SOMDS Provider detects a stepping system clock adjustment, the SOMDS Provider shall initiate a new MDIB sequence. would be my preferred wording for 2, given that "stepping system clock adjustment" is a well-known term (I am not familiar with the wording of NTP at all). Is it really required to agree on a threshold here? Shouldn't smaller changes to the clock be covered by clock slewing? Other than that it looks good to me. |
I propose this variation to the last proposal to make it a bit more specific/testable: After further pondering on the need for a threshold (note that also I am NO expert in NTP or clock synchronization! ) I think I agree with you, @d-gregorczyk. A slewing adjustment should not imply the tiniest step in the clock counter (above its resolution) ..it's just that the counter changes faster or slower during the adjustment process. |
@JavierEspina: Hi. I was just sorting the unfinished issues for version 1.2. Can we close this or is there anything left to do? |
Hi @AnnaFeiler (and Happy New Year!). This issue is still open, which is not so obvious here but more so in the associated pull request. I propose to shift it to the 1.3 milestone. |
Non-slewing adjustments will break time synchronization. Unfortunately, we cannot completely prevent them. Specify what will happen in case of a non-slewing adjustment. If possible, also add ntp configurations that will make this scenario less likely.
The text was updated successfully, but these errors were encountered: