11-08-2019 10:51 AM
No I do not have any code to share (it would take you hours to see it event if I did share the code and a bunch of cRIOs).
I have an application allows a Windows based application (developed by me) to monitor hundreds of cRIOs.
I spin-off a background task (Monitor) for each cRIO that handles the TCP/IP traffic to and from the cRIOs.
Each of those Monitors keeps track of the last time (Windows System Time) an update was received from its cRIO. When the Monitors check for an incoming update (happen four times a second, with updates expected about once a second), and none is found, the I subtract the "Last Update Time" from the current time in order to detect cRIOs dropping off-line or failing.
What I have noticed is that ALL of the connected cRIOs are detecting this "Time Out" in batches (all log the same error within seconds of each other) that occur maybe eight hours between these events.
I am guessing I may be seeing Windows adjusting its clock but I am not sure how to confirm that.
I could also switch over to using the (better option) of using the ms tick count but for now I am curious what all of YOU can say.
Have you seen Time Warps Jumps?
Ben
11-08-2019 11:03 AM - edited 11-08-2019 11:34 AM
On a related note, have a look at Ed's talk here (slide 8, part 1)
11-08-2019 11:07 AM
11-08-2019 02:00 PM
I'm not sure about Windows Time, but with NTP, it is constantly adjusting your clock at intervals determined by some algorithm. I don't know if Windows does the same thing, though.
11-08-2019 03:53 PM
@Ben wrote:
I could also switch over to using the (better option) of using the ms tick count but for now I am curious what all of YOU can say.
This is what I was going to recommend as an alternative but I see you've already mentioned it. If this is a system with a lot of uptime, don't forget to put in a special case so that it doesn't give you false timeouts every 49.7 days (2^32 milliseconds). I guess even if you didn't, one set of false timeouts every 49.7 days would be better than the ~150 you'd get now.
11-10-2019 07:18 AM - edited 11-10-2019 07:26 AM
@Kyle97330 wrote:
This is what I was going to recommend as an alternative but I see you've already mentioned it. If this is a system with a lot of uptime, don't forget to put in a special case so that it doesn't give you false timeouts every 49.7 days (2^32 milliseconds). I guess even if you didn't, one set of false timeouts every 49.7 days would be better than the ~150 you'd get now.
There is a little trick you can use. The timer tick value is an unsigned 32 bit integer. If you store the last timer tick and subtract it from the current timer tick the difference is always positive and always the right value even when the value of the timer tick rolled over without any special casing code (well except of course if the actual interval between two consequent timer tick values spanned more than the 49.5 days you mention! But I'm sure that chance can be ignored 😀). This is an inherent feature of the 2 complements arithmetic used in all current CPU implementation when applied on any unsigned integers.
On another note about the original topic, Windows did use to make aprupt time adjustments when configured to synchronize to an internet or other time normal, but they improved that at some point to make small gradual adjustments spread over a longer period to minimize the effect you are seeing here. I'm not sure if that change was already present in Windows 7 or if it was introduced after in Windows 8 or maybe even only Windows 10. This article may be interesting reading on this topic.