Whether to allow setting time in NTP mode

Whether to allow setting time in NTP mode

[George Liu]

Hey, everyone:

  This email would like to discuss whether to allow the requirement to
set the time when NTP is enabled.

  In the phosphor-time-manager, The current design logic is:
  1. The timeManager will listen to the TimeSyncMethod property of the
xyz.openbmc_project.Time.Synchronization interface to set the SetNTP
method of timedate1 and update the current Time mode. [1]
  2. When the user changes the time using OOB, the timeManager does
not verify the current Time mode, and directly calls the settime
method to change the time. If the current is in NTP mode, setting the
time will throw an exception. [2]

  But there is a potential problem here:
  When the user sets the mode from NTP to manual by way of OOB, then
the time is set immediately. At this time, there will be an error in
setting the time because the NTP service is not completely stopped,
but we do not want to throw this error to the user, because for the
user layer, the mode has been switched to manual (TimeSyncMethod =
Manual)[3]

  I have a patch that determines whether the current NTP service is
completely stopped (a timeout mechanism is added) when setting the
time [4]. But @Lei suggested that this mechanism should not be
implemented on the timeManager server side, but should be handled on
the client side.

  Also, @Lei also has a different idea downstream, using settimeofday
instead of timedate1

  I would like to hear everyone's suggestions, and I would like to
optimize this function if appropriate.

Thanks

[1]: https://github.com/openbmc/phosphor-time-manager/blob/master/manager.cpp#L28-L31
[2]: https://github.com/openbmc/phosphor-time-manager/blob/43dfeeb1e22d6d7fcec9f1d4be81f3e9d6857e62/bmc_epoch.cpp#L120-L139
[3]: https://github.com/openbmc/bmcweb/blob/07c8c20d371aae85611738ca61015fc6a8caa16a/redfish-core/lib/network_protocol.hpp#L215-L240
[4]: https://gerrit.openbmc.org/c/openbmc/phosphor-time-manager/+/56584


George Liu

Re: Whether to allow setting time in NTP mode

[Lei Yu]

On Mon, Sep 19, 2022 at 5:06 PM George Liu <liuxiwei1013@gmail.com> wrote:
>
> Hey, everyone:
>
>   This email would like to discuss whether to allow the requirement to
> set the time when NTP is enabled.
>
>   In the phosphor-time-manager, The current design logic is:
>   1. The timeManager will listen to the TimeSyncMethod property of the
> xyz.openbmc_project.Time.Synchronization interface to set the SetNTP
> method of timedate1 and update the current Time mode. [1]
>   2. When the user changes the time using OOB, the timeManager does
> not verify the current Time mode, and directly calls the settime
> method to change the time. If the current is in NTP mode, setting the
> time will throw an exception. [2]

For the record, the exception is thrown due to the DBus call to
`org.freedesktop.timedate1` service failure.

>
>   But there is a potential problem here:
>   When the user sets the mode from NTP to manual by way of OOB, then
> the time is set immediately. At this time, there will be an error in
> setting the time because the NTP service is not completely stopped,
> but we do not want to throw this error to the user, because for the
> user layer, the mode has been switched to manual (TimeSyncMethod =
> Manual)[3]
>
>   I have a patch that determines whether the current NTP service is
> completely stopped (a timeout mechanism is added) when setting the
> time [4]. But @Lei suggested that this mechanism should not be
> implemented on the timeManager server side, but should be handled on
> the client side.

The reason is that the time-manager will have to "wait" until the time
could be set and it effectively blocks the event loop in the patch
mentioned above.
It could be resolved by making time-manager async, but it's off-topic.

>
>   Also, @Lei also has a different idea downstream, using settimeofday
> instead of timedate1

We have a requirement from the users that the "set-time" should be
successful even if the BMC is in NTP mode. (Be noted that the time
will be updated by NTP after a short while).
To set the time, use `settimeofday` instead of making DBus call to
`org.freedesktop.timedate1` service solves the above issue, and it
meets our internal requirement.
If we all agree that this is the expected behavior, I could send the
patch upstream.

>
>   I would like to hear everyone's suggestions, and I would like to
> optimize this function if appropriate.
>
> Thanks
>
> [1]: https://github.com/openbmc/phosphor-time-manager/blob/master/manager.cpp#L28-L31
> [2]: https://github.com/openbmc/phosphor-time-manager/blob/43dfeeb1e22d6d7fcec9f1d4be81f3e9d6857e62/bmc_epoch.cpp#L120-L139
> [3]: https://github.com/openbmc/bmcweb/blob/07c8c20d371aae85611738ca61015fc6a8caa16a/redfish-core/lib/network_protocol.hpp#L215-L240
> [4]: https://gerrit.openbmc.org/c/openbmc/phosphor-time-manager/+/56584
>
>
> George Liu



-- 
BRs,
Lei YU

Re: Whether to allow setting time in NTP mode

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 441 bytes --]


Typically, when the time is very very far away from the synchronized NTP
time, NTP is unable to change the time.  So while NTP might be synchronized
with a NTP server, it is unable to force the time in a gradual way.
This is often the case where the system time is in the future.
An administrator usually has to force the discontinuous time jump.

So, it seems entirely reasonable that the time should be able to be set while
in NTP mode.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]