Time namespaces

Posted Sep 23, 2018 16:50 UTC (Sun) by rweikusat2 (subscriber, #117920)
In reply to: Time namespaces by kiryl
Parent article: Time namespaces

Well, yes. But if they were scheduled for some absolute time, they should fire. It's not generally possible to stop a real-time bound task and restart it much later without wreaking some havoc on it.

Time namespaces

Posted Sep 23, 2018 17:36 UTC (Sun) by kiryl (subscriber, #41516) [Link] (1 responses)

Of course it's possible. ntpd is able to adjust time from wrong to right in a safer manner.

Time namespaces

Posted Sep 23, 2018 18:52 UTC (Sun) by rweikusat2 (subscriber, #117920) [Link]

Quoting the ntpd documentation (-x option)

Normally, the time is slewed if the offset is less than the step threshold, which is 128 ms by default, and stepped if above the threshold. This option sets the threshold to 600 s, which is well within the accuracy window to set the clock manually. Note: Since the slew rate of typical Unix kernels is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s. Thus, an adjustment as much as 600 s will take almost 14 days to complete.

Leaving this non-possibilty aside, this doesn't help with a real-time bound task. Eg, using an example I'm familiar with, an IKEv1 ISAKMP SA usually has a fixed, negotiated lifetime and there's another party to it. It's not possible to stop the task manageing the SA and later restart it in a virtual past because the lifetime of the SA will end on time, regardless of any local clock fudging. The outcome will be a VPN communication breakdown until the 'confused' IKE task has again caught up with the real universe outside of it.