search

Oughie / clock-rs

clock-rs - A clock for your terminal!
Apache License 2.0
27 stars 2 forks source link

Clock is not synced with system clock #3

Closed Reyhn3 closed 1 month ago

Reyhn3 commented 1 month ago

When starting up more than one instance of clock-rs (in separate terminals), they are not synchronized, meaning the seconds are updated at different times. Please see the attached video.

https://github.com/user-attachments/assets/689f3669-696e-47e0-a634-15e2998a83ad

This is a "nice to have" (after all, why would you run multiple instances of the clock?), but it would look better if all instances updated their time at the same time as the system clock.

However, there is a more serious bug hidden here! The clock is drifting, somehow. Look at the left-most clock from second 34 -> 35. The increment happens too fast. If you just start up any clock and watch the seconds updated, you will eventually see that some second increments happen too soon. At the end of the video, the left-most and the bottom-right clocks are almost synced.

Without looking at the code, I guess there is a timer that triggers on the specified interval, counted from when the application was started, which is why it is not synchronized with the system clock. I am guessing that both of these bugs stem from the same root cause and will be solved with the same fix.

Tested on Windows 10 using the Command Prompt and version 0.1.201 of clock-rs.

Oughie commented 1 month ago

Thank you for opening an issue! ^^

To achieve better synchronization across multiple clocks, you can reduce interval to e.g. 10ms. Considering that this would result in higher CPU usage and it is uncommon to run multiple clocks at once, I don't think this is a real problem. Did you specify the interval in milliseconds using --interval <ms>?

I've taken a look at other terminal-based clocks such as tty-clock, xclock, etc., but they all seem to have the same problem that they won't fix. Also see here on how other clocks fix this issue. I value resource usage over accuracy.

I thought about waiting until the next full second on startup to ensure synchronization, but this would just result in an annoying delay. Over time, they would begin to differ again anyways.

Furthermore, the faster increment occurs because of the interval as well: if you were to run $ clock-rs -i 900 for example, the increment would alternately between faster and slower. It's best to choose a number, that, when approaching one full second, wouldn't have a big difference compared to it, e.g. 100ms, 200ms or 500ms, instead of numbers like 900ms or 700ms, which would have both end up at 1800ms and 1400ms and deviate from the ideal 1000ms! Choosing an interval like 10ms would therefore resolve this issue, but also cause a higher CPU usage.

In most scenarios, clock applications like these aren't actually useful, but exist more so for aesthetic reasons. It might not be too important if a second was displayed for a short time compared to the others, as long as it doesn't occur too often. Currently, the default is 500ms, so I might consider lowering this a bit.