CTR works with PXI 8196,PXIe 8102, fails with PXIe 8100 - why?

Question

My client has reported a problem.  
For years he has used a PXI 8196 RT Controller with PXI 6602 Counter card and my software has given good results.  They have 20+ of these systems and they have worked well.
Now they are moving to PXIe 810x controllers, for cost reasons.
WIth a PXIe 8102, the same code also works perfectly, measuring total counts over a period, as well as instantaneous frequency.
With a PXIe 8100 - the exact same code reports DIFFERENT answers. The reported frequency is always 1% HIGHER than actual (For example, a known 4500 Hz input is reported as 4500 Hz on 8102, but as 4545 Hz on 8100.
This happens on any channel, and swapping just the controller will make the problem come and go.
Here is the CONFIGURE code, where the channels are set up (again, this has worked for years).
Here is the SAMPLE code:
Basically the CONFIG code configures the thing to count edges.   I do this because they need an accurate count over a 20-minute period, in addition to instantaneous frequency readings.
The AVG TIME is a user-settable number defining how long a period to average, when showing the "instantaneous" frequency.
So, I create a buffer for N samples, corresponding to that period.
At SAMPLE time, I read the counter.  I replace the oldest value in the buffer with the newest, then subtract the newest - oldest to get the total counts in the sample period.
The PULSES PER COUNT item is a scaler, to account for a 60-tooth wheel, or something.
So, this same code has worked perfectly for years, until I plug an 8100 code in.  Then the result changes by 1 %, and EXACTLY 1%?
The CPU burden on the bad controller is 31%.
Any ideas?
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks

Answer 1

Well, the controllers are not in my own hands.  I have an 8196 controller and on that, the CPU time is between 2 and 4%.
But the 8100 and 8102 controllers are in my client's hands.
I haven't gotten any hard timing numbers other than I saw the 31% figure reported on the video monitor.
It's hard to believe that it would be EXACTLY 1% if it was CPU overburden.
My software includes a calibration facility; here is a run from the good 8102:
Here is a run from the 8100:
This was with a reference digital freq generator.  You can see the one case where everything is within 0.1 Hz.
the other case has everything EXACTLY 1% higher.  My only explanation is that the scan engine is running 1% slower.
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks