Accuracy of Timed Loop

[CoastalMaineBird]

NOTE:  I have turned this from a question to a warning, because I solved it just before hitting POST.

LVRT 2013, PXI 8196 controller.

I am new to Timed Loops.

In researching how they might fit, I came up with the following test.

Set a NI-DAQ task to sampling, at 10 Hz

Set a TIMED LOOP to run at 10 Hz.

Have the LOOP wait for a sample from NI-DAQ.

Record the DURATION of the loop iterations.

I realize this is not a sane way to do sampling, but it is a way to compare the clock rates.

What I EXPECTED was a number above 90000 (uSec), with a slow drift up or down.  The timed loop is not synchronized to the hardware, so the loops would run at a slightly different rate.  I understand that.

What I GOT was a number above 90000 (uSec), with a NOSEDIVE toward 0. In 50 samples, it lost all the 100000 uSec.  The lower part of that trace s a steady 6 uSec, +/- 1.  That's the time it takes to retrieve a sample THAT'S ALREADY THERE.

The point at which it loses a sample is not constant. sometimes it's 6 seconds, sometimes 4.

If I change to 1kHz clock, instead of 1 MHz, behavior is the same.

Losing 0.1 second in 5 Second is about 2 %.

Is that as good as it gets?  Am I missing something?

Just as I was about to hit POST, I recalled a sort-of similar situation I discovered some years ago.  Can't find the exact topic, but it was comparing CPU timing to hardware, and the CPU timing was unreliable.

I eventually found the problem when  I ran a test the frst thing in the morning, and the answers were perfectly correct. 

But as time went by, they got worse and worse.

Eventually, that led to me discovering that the air filters on the back of the PXI box were very dirty.  The CPU was running hot, and trying to protect itself by slowing down.  So, anything based on CPU timing was erroneous.

That was the case here, as well.  I washed out the filters, and now I get exactly what I was expecting:

WARNING:  Keep your PXI air filters clean.  CPU Timing will suffer if you don't.

[Norbert_B]

Thanks for sharing this, Steve.

It really is an impressive display of the effect temperature has on clock stability!

I think i should bookmark your post if i talk to someone else who doubts that dirty filters at fans have a significant impact on measurement accuracy and timing!

thanks,

Norbert

[CoastalMaineBird]

For the record, here is the post I mentioned.    there was a 12-15% discrepancy between hardware timing and software timing.

You were in on it, Norbert.  As a matter of fact, YOU are the one (post 16) who suggested the FANS were blocked!

[Norbert_B]

Well, thanks for the compliment, Steve. I just wanted to point out that even i know that temperature has a big impact on accuracy of measurement values as well as clock stability, i wasn't aware that it could be THAT big 😉

Therefore, i could use your benchmarks as proof in the futuer 😛

Norbert

[CoastalMaineBird]

Well, be aware that this is not just a case where the temperature affects the electronics directly.  It's the CPU, measuring it's own temperature and deciding that it's too hot, so it dials down its own clock rate, so that it doesn't generate as much heat internally.

All the internal Timed loops and such assume that they know the CPU clock rate and base things on that assumption.

But if the CPU clock rate changes, that assumption doesn't hold any longer and all bets are off.