search

IHE / DEV.SDPi

IHE Devices Service-oriented Device Point-of-care Interoperability (SDPi) profiles supplement specification materials and related tooling.
9 stars 1 forks source link

Non slewing time adjustments #203

Open AnnaFeiler opened 1 year ago

AnnaFeiler commented 1 year ago

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.

ToddCooper commented 1 year ago

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.

JavierEspina commented 1 year ago

@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. <Issue/PR reviewer's note: the 10 seconds is a - wildly - guessed value in between the CT Clients' "median error of less than one second" and values high enough to likely cause noticeable metrics charting issues. While the value is guessed, I think we do need a minimum value under which (little) steps are acceptable (as they may happen regularly due to drift/jitter)...else what would be the minimum step size to consider the step to be a step at all?>

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.

d-gregorczyk commented 1 year ago

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.

JavierEspina commented 1 year ago

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: When the SOMDS Provider detects a stepping adjustment of its system clock, the SOMDS Provider shall initiate a new MDIB sequence by assigning a new MDIB sequence identifier.

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.

AnnaFeiler commented 10 months ago

@JavierEspina: Hi. I was just sorting the unfinished issues for version 1.2. Can we close this or is there anything left to do?

JavierEspina commented 10 months ago

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

ToddCooper commented 5 months ago

SDPi Workshop #3 2024.06.04:
State: Determine how best to provide CONSUMER with sufficient information to be able to adjust the time if necessary. IOW consumer must have the final decision to adjust or not.

See PR #238