Clock fixable?

[pbelbin]

I'm trying out 'ontime'.

Looks interesting and useful.

Here it comes:

But, during testing, I'm finding that when I have the Docker image (latest build) on a windows machine, and I have NTP (Chrony) configured within, and seemingly the terminal shows a fairly good correlation with what the https://www.time.is shows, that ontime's browser clock is not keeping good sync.

Seems like it's kinda free-running and periodically resyncs, and between those resyncs, the time slips further and further behind.

So, the clock kinda 'jumps' back into sync for a moment, and thereafter, it progressively falls behind, until the next 'jump' back to correctness.

For a tool that tries to keep everything running like clockwork, this seems to be an odd behavior.

Can it be fixed somehow? Is there something I'm supposed to do? It kinda looks broken to me.

[cpvalente]

Hi @pbelbin , thank you for reaching out and for your very detailed specification.

I just want to send you a message to say that we are looking into it.
I am not entirely sure what the ideal behaviour is here.

Few things at play:

• Ontime uses your system clock. Usually operating systems are pretty good at learning their internal deviation and correcting it. However I am unsure on how docker containers handle this.
• The window from Ontime to be out of date is 32ms + network time. This just to update the UI, all the network traffic for integrations comes out before in a higher priority update. I will try to analyse if what we are seeing here is correct.

I appreciate your feedback, we will investigate and get back to you.

[pbelbin]

Hey there. Thank you for letting me know you're taking a look.

I'd be very interested in what you find, and what the solution is.

[cpvalente]

HI @pbelbin,

I took some time to evaluate the issue and agreed that, even if this does not affect the functionality of the application, it does affect the confidence users take from it.
Asides from that, there is no good reason for us not to be more accurate.

You can see part of the conversation in the pull request at #955

I have made an initial proposal which improves the stability of the timer. This has been merged and is part of the new release v3.0.1. It would be great to have your thoughts on it

Meanwhile, we have a few more ideas to explore and we will likely improve this further in the near releases

Thank you again for your help

[cpvalente]

Closing this issue for now, please feel free to reopen

[pbelbin]

Thank you for the updates provided so far! It's definitely an improvement in terms of the clock not drifting out of sync.

Ummmmm, hate to rain on the party, but.... trying the latest install via Docker on windows desktop, I'm finding that now, the clock periodically jumps over a second every now and then.

I'm kinda wondering.....

It seems to be receiving via the websocket a heartbeat every second (well, aside from those that it skips).

Now, I don't know anything of the internals, so, forgive me if I'm describing things that are already happening:

I did observe the per-second heartbeat arriving via the network.

Bearing in mind my lack of understanding what it's really doing, but, I'm wondering if this is the best way to do it. Particularly since this relies on a message per second, if I have it right?

Perhaps an alternative would be that if you are able to send a hearbeat message every so often (not every second), and calculate the round trip time, and that half of that round trip time is the network latency (simple, not always accurate, I know, perhaps there's better ways to do this), then in the browser, you'd be able to calculate local offset versus server time, and, between periodic heartbeat updates, determine the amount of local drift that's happening, so that the browser can somewhat keep locally accurate time, with periodic small adjustments.

Perhaps you're already doing some of this.

Also, if the schedule of upcoming events for the next handful of events (at least) is sent out to the browser ahead of being needed, and let the browser kind of display what it needs to at the right time based on the in-browser sense of time. ie: it would not need to rely on having a fast & reliable network to make it work as the browsers would have the schedule of up-coming changes, and operate somewhat autonomously, rather than having everything relying on the network to distribute time sensitive information.

Of course, if you have a situation where the user is clicking manually something, this would still need to be sent over the network in the moment, but the details as to what the button press triggers would already be in-hand in most cases.

[pbelbin]

@cpvalente , I don't see a way to reopen this issue, by the way!