First ever error reading from VP2

[mcrossley]

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!

Code: Select all

Fine Offset...
17/04/2014 22:54:06 : Lost sensor contact!!!
17/04/2014 22:54:16 : Lost sensor contact!!!
20/04/2014 00:59:53 : Data input appears to have stopped - check your station and connections

VP2...
20/04/2014 00:59:54 : Data input appears to have stopped - check your station and connections

Investigation shows that the Windows clock was corrected at this point, from the event log...

Code: Select all

Previous Time:		‎2014‎-‎04‎-‎20T00:00:01.862643100Z
New Time:			2014‎-‎04‎-‎19T23:59:52.585203700Z

This event is generated when the system time is changed. It is normal for the Windows Time Service, which runs with System privilege, to change the system time on a regular basis. Other system time changes may be indicative of attempts to tamper with the computer.

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.

[steve]

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.

[mcrossley]

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?

[steve]

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

[water01]

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

[mcrossley]

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.