Get system time and date changing PC clock

[teslac]

    In my code I time stamp the data using Get system time and date which is fine but, what I have notcied is that now the PCs clock is drifting.  The drift over 8 hrs can be as much a -20 minutes from UTC GPS time.  This only happens when I use this code.  There is nothing in the code that should effect the PC time onther than getting the time and date stamp.  Finally, the code runs at 1 Hz.  Has anyone seen this before?

Regards...

[RavensFan]

No.

Does the clock drift if you aren't running your LabVIEW code?

What if you run your code on a different PC, does it drift then?

[teslac]

RE: It does not drift if the code is not running.  I also checked the BIOS clock and noticed it drifts when the code is running.  I have not check it on other PCs since the systems configured for a particular DAQ opperation.

[JamesB.]

UTC time and GPS time are not the same. See our KnowledgeBase article or this summary.

In your system, what process or tool do you believe should be keeping the system clock aligned with global time? What operating system are you using? What kind of processor (PXI controller model number, desktop PC purchased from X, custom-built, etc.)? Do you have a network connection? Are you running NTP or PTP? If there is nothing keeping the system clock aligned, I would expect to see a small drift over time. But (a) losing 20 minutes over 8 hours sounds big to me, and (b) I wouldn't expect the drift to be different when you stop your application.

[teslac]

I agree with you accesment.  The DAQ in on a rack PC using Windows 7 and is on the network that syncs its clock from our server.  I use the system time to tag the data so the pfoject can correlate the data in post.  They get thier time off a GPS link that they then convert to UTC.  Ive talked to our IT and they also see no reason for the drift nor have a solution or why the appliation would affect it since it only queries the time.

[Bob_Schor]

I find it very hard to come up with a scenario where running a LabVIEW program that doesn't mess with the PC hardware would cause the System Clock to lose time.  However, I could certainly design a program that supposedly kept track of time, but through sloppy code, "ran a little slow" and appeared to lose time -- a Software Glitch.

I suspect that is what is happening.  It would be interesting to see your code and to see if we could Find the Bug ...  

Bob Schor

[Yamaeda]

---

@teslac wrote:

    In my code I time stamp the data using Get system time and date which is fine but, what I have notcied is that now the PCs clock is drifting.  The drift over 8 hrs can be as much a -20 minutes from UTC GPS time.  This only happens when I use this code.  There is nothing in the code that should effect the PC time onther than getting the time and date stamp.  Finally, the code runs at 1 Hz.  Has anyone seen this before?

Regards...

---

I actually had a similar problem at my former job. In that case it was out virtual servers drifting during normal operation, no LV involved. Are you running virtual machines?

/Y

[Matthew_Kelton]

I had an issue 15+ years ago where this happened, and it ultimately was NI hardware causing the issue, but we were consuming so many resources of the PC, the clock could no longer keep time.  We would run something that should take 10s, it would take 30s.  I noticed finally that the clock was actually slowing down, and LabVIEW was doing what it thought was right.

But, as I said, this was Windows 95 or 98, with the OLD NI parallel port DAQ card, and the driver for that simply was never designed to continuously acquire data.  The PC was probably being flooded with interrupts.  But, you may wish to confirm you are not pushing the CPU at 100% while your code runs.

[Yamaeda]

That was my second thought, could some cpu burner loops prevent windows from keeping time?

/Y