My applications clock(date and time) is too fast?

Question

I have an electron.js application installed in a raspberry pi. The app displays date and time, the initial date and time is taken from a server and is incremented on the application using setInterval with a 1000 ms timer. What's weird is I have 3 of this devices running the same application, initially all the dates and time are the same but one of the devices is now ahead of the other 2. The application has been opened for about 5 hours now and one of the device is ahead about 12 seconds.

Answer 1

setInterval is inherently not accurate (as can be seen here)

Not sure what code you used, but if you are not using Date, you might want to consider it.

i.e the following example will drift

var displayDate = 0; // the date to be displayed

setInterval(() => {
  displayDate++;
}, 1000);

And this will not:

var startDate = Date.now(); // Date in MS since 1/1/1970
var displayDate = 0;

setInterval(() => {
  displayDate = (Date.now() - startDate) / 1000;
}, 1000);

Answer 2

I still wondered how that could be a code issue when the code was fine on other pi's

Did you have a look at the Stack Overflow Q&A that Tomir linked? Read in particular the accepted answer and the other links provided therein. The basic issue is that javascript/node.js is not the operating system, and it is the operating system it must depend on, but modern multi-tasking OS's do not actually provide the kind of guarantees perfect accuracy would require here. A couple of points about this:

• That something like this usually or mostly works does not mean that this is because there some guarantee that it will be perfectly accurate. At the same time there is no guarantee, there is a pretty good chance that it will, and in that sense, 12 seconds of drift in 5 hours is actually not bad. It is totally sufficient for the kinds of things setInterval would normally be used for, short durations in timed UI events.

• The reason the OS does not guarantee perfect timing of this sort is that there is a degree of indeterminacy in the operation of a contemporary, multi-tasking operating system. This is because, even when you have a multi-core system, they must time slice tasks because there are almost certainly too many of them running at any given point to devote a core to each of them for as long as they like -- that would be a very much more specialized environment.

  "Time slicing" does not mean I let process X run for exactly and precisely 1512 ms, etc. It means I let it run until I want to interrupt it, and at that point there are rules -- conventions, and ones that derive from the physics of electronics -- about exactly how it can be interrupted. You cannot use some arbitrary wall clock nanosecond. In essence, it happens when the process can be interrupted. Or you might look at in terms of how long it takes to interrupt it, which is indeterminate within certain bounds (it isn't going to be minutes or hours or generally even seconds, but it will not be precisely 150 ns every time, etc).

Hence, userspace operations (that's non-kernel code) are considered to have a certain latency. For example, on standard linux as runs on the pi, if you want to do extremely high frequency things, the latency/precision is probably going to average 20-25 ms under the best of normal circumstances. Things that require better precision than this have some implementation in hardware, meaning they have some direct wiring to a clock. Buses like USB (and SPI, and I2C, and UART) work this way.

What that latency translates to, if you are trying to measure time very precisely, is drift.

For things that need to be timed over a long period, or stay in step with a wall clock, the normal approach (and the one Tomir recommends), is to use the system time. Think of it like this: You and I are sitting somewhere, and I have a watch, but you do not. You need to do something in exactly ten minutes. However, I am not going to time it for you because I am busy. What I will do is tell you the exact time when you ask for it.

Asking every five seconds is going to turn into a lot of wasted time for everyone. So, you could count in your head two minutes and then check to see how accurate you were by asking me. If the time I give you is 135 seconds after the last one, you know that more than two minutes has passed and you know exactly how much more, so some simple arithmetic is all you need.¹ This isn't a perfect analogy (setInterval() is not mouthing numbers in the background), but hopefully the point is clear.

The system time actually can drift too, which is why online computers (including pis) now normally periodically sync with a timeserver; network timeservers eventually all converge on the best ones, which will use atomic clocks in some facility somewhere (which use cesium instead of quartz crystal oscillators). Sans that, this amount of drift is generally pretty small, however -- fractions of a second a day.

---

1. So why doesn't setInterval() do this under-the-hood? Because while that approach might work when the time is less than requested, the callback does not include a parameter to indicate how much it went over by, if it went over. But of course, you can check directly by consulting the system time in the callback...