Time to complete DAQmx tasks inconsistencies

[Foreshadow20]

Timing to complete a simple DO write seems to vary every now and then.

I have a Producer-Consumer based Test Sequencer (built into *.exe). I monitored all of the delays of completing tasks and I noticed something odd with DOs in particular. I extracted 991 DO Write tasks (all using the same code to command the 6225 card) over 23 tests. All the states (get step to end step) around the DO commands take 0 to 1ms time to complete.

71 DO steps took 1ms

15412 DO steps took 2ms

7109 DO steps took 3ms

187 DO steps took 4ms

3 DO steps took 5ms

3 DO steps took 6ms

1 DO steps took 7ms

1 DO steps took 17ms

1 DO steps took 26ms

1 DO steps took 27ms

1 DO steps took 30ms

1 DO steps took 36ms

1 DO steps took 284ms

1 DO steps took 295ms

I'm running a PXI system with Windows 7 (not Real-Time) and the DO card is a PXI-6225.

I can understand some steps taking up to 4 ms on a Windows OS, but its harder to understand why some would take much longer. 15 of 22793 took longer than 5ms.

Attached is the Matrix of all the timings for DOs.

DO calls always have Open and Close tasks. Auto Start is defaulted at False. Timeout is default.

Otherwise:

All AIs (6723) are 15 or 16ms and AOs (6723) are 2 to 4ms.

FPGA (7853) did take a lot of time to process:

Sinewave generation commands took 231 to 239ms.

DO signals took either 31-40 or 100-300ms

Thanks

[Foreshadow20]

Space for extra info if needed.

[Kevin_Price]

FWIW, the main thing I find surprising in that distribution of times is that they are both faster and more consistent than I would have predicted.

Considering that you're creating and clearing the task for each of these DO steps, I'd have expected many more msec of overhead.  I'd also expect a more than just 7 out of over 22000 to exceed 10 msec.  Those 2 that approach 300 msec would trouble me, but it wouldn't shock me that they exist.  I'd put a little effort into trying to prevent those, but without certainty of success.

In short this seems, at a glance, to be a fairly typical case of Windows timing variation.  I've seen worse.

-Kevin P

[this_one_time_at_vancamp]

Foreshadow20, I agree with Kevin_Price. Because you are not using LabVIEW Real-Time, you are at the mercy of Windows when it comes to reserving processor time. It is unlikely that any modifications to code will change the amount of jitter associated with this. If your program architecture could somehow allow you to create and clear the task outside of the DO step, this may help, as the bulk of the processing time may be going to creating and clearing the task. Other than this modification, the jitter you see is most likely to be expected.