[reactive] Clock skew corrections

[Robin Green]

What happens if the system clock is running too fast, this is noticed,
and the system clock is corrected, during a program run? I think this
could break temporal monotonicity of occurrences in events, as
FRP.Reactive.Internal.Clock doesn't know about system clock corrections.
Am I right? If so, what, if anything, should be done about it?

One rather inefficient approach would be to have a global mutable
variable and a mutex for that variable, to record the last known time
"reading" for the entire system, and a temporal adjustment factor
(initially zero). If the difference between the last reading and the
(adjusted) current reading was a positive number, that difference would
be added to the temporal adjustment factor. This would prevent temporal
monotonicity being broken.
--
Robin
_______________________________________________
Reactive mailing list
Reac...@haskell.org
http://www.haskell.org/mailman/listinfo/reactive

[Svein Ove Aas]

On Tue, Aug 25, 2009 at 12:05 PM, Robin Green<gre...@greenrd.org> wrote:
> What happens if the system clock is running too fast, this is noticed,
> and the system clock is corrected, during a program run? I think this
> could break temporal monotonicity of occurrences in events, as
> FRP.Reactive.Internal.Clock doesn't know about system clock corrections.
> Am I right? If so, what, if anything, should be done about it?
>

To avoid just this sort of thing, clock daemons (..ntpd) normally use
adjustment methods that slightly slow or speed up the clock instead of
outright stepping it, which maintains monotonicity. Stepping should
only be used at system startup. Still..

> One rather inefficient approach would be to have a global mutable
> variable and a mutex for that variable, to record the last known time
> "reading" for the entire system, and a temporal adjustment factor
> (initially zero). If the difference between the last reading and the
> (adjusted) current reading was a positive number, that difference would
> be added to the temporal adjustment factor. This would prevent temporal
> monotonicity being broken.
>

That's exactly the approach I'm taking in my implementation. It's not
*that* inefficient.

--
Svein Ove Aas