Cumulus Support

ON 20/04 @ 00:59:54 I had my first ever error reading data from the VP2, turned out teh second Cumulus instance reading from the FO had the same error 1 second earlier - suspicious! Investigation shows that the Windows clock was corrected at this point, from the event log... Never seen that happen before (Cumulus log the error that is, not the clock being corrected). I just posted this out of interest, no big deal.

Going backwards in time over a minute boundary will tend to trigger the 'data stopped' code, because the check is done in the code which runs when the minute changes (which would normally be once a minute). It's not easy to cater for this situation.

Having Windows adjust the clock at midnight in particular is risky and may cause you some problems.

I have changed the update interval from the default of 1 week to 2 hours, and started the sync at xx:46. So the new interval should mean any future corrections are small, and will not occur on the hour. Seems like the best you can do?

I thought you could set it to to do it at a specific time, using Task Scheduler?

Yes you can. It is Task Scheduler under Microsoft/windows/Time scheduler.

Ah, it seems there are two independent schedules. The W32time service itself has its own update schedule, you can see this from system tray|Date & Time|Internet time. Here you will see the last time the service updated the time and the next time it is scheduled to check again. The interval being controlled by a registry setting for the ntpclient, and the time controlled by when you press 'update now' (and when you reboot?).

The task scheduler also has a job that triggers a synch at 01:00 every Sunday - presumably to catch DST changes?

Both settings appear work independently of each other.

Funny but I remember I had some in-depth conversations with the original author of the Windows time service back in the day when I was writing an NTP client time synchronisation program for the BBC micro over dial-up networking.