[Greg McKaskle]

There are a number of issues contributing to what you are seeing, so I'll start by saying that NI does I/O in two different ways -- SW timed and HW timed.

HW timed I/O uses clocks on the board to sample the signal and store the value into board RAM. The PC driver and/or board ASICs will acquire the PC bus and move board memory into driver RAM and eventually into a buffer that can be accessed by a user program. The timings are accurate, the measurements are accurate, the throughput can be quite high, but these are not realtime measurements. The other name NI uses for this is a buffered measurement. The data buffers are typically available within a few ms, and the consumer PC can then filter, trigger, perhaps do control, but with the knowledge that there is a bit of lag and that the output rate is not the same as the acquisition rate.

SW timed I/O allows the user program to request a point at any time. This may be based on a screen button being pressed, a key, a trigger of some other measurement, or an OS timer. On realtime targets, the resolution and consistency of the OS timers is far better, and you can start to get the point-by-point processing at pretty high speeds, with good determinism using SW timing.

Looking more closely at the timing, you mentioned the timed loop, but the code you posted used two types of SW timer, the Wait ms, and the Express timer (blue one). The one you wired 100 ms to is the Wait ms, and as the name implies, it takes an integer number of ms and throttles the loop to no faster than that period. The OS has no guarantees, so the timer doesn't either.

The blue Express timing block is a beginner block that does the scaling for you, but is just a wrapper on the Wait ms. You can see this only if you right click and look at the Front Panel. As with the other block, once it adjusts to ms, it changes to an integer type. As the period shrinks to 0.5 ms, you get rounding into the node and this is why your panel showed that your loop actually ran more iterations than it should have.

The timed loop is a structure designed for the realtime OSes, but also made to work to some degree on desktop OSes. The timed loop can be driven by a selected timing source and has a number of calculations and scheduling policies available to you. If the OS has a way to sleep or schedule at microseconds, the loop exposes it. For Windows, your clock choices are limited, but the loop does offer better policies for adjusting the calculated period to achieve an overall rate. Obviously the timing between individual points will have the noise from the scheduling clock being used.

The not surprising summary of the timing area is that desktop PCs are readily available and can be made to do a good job at certain types of tasks, but unless you remove the desktop OS or supplement with another micro and OS, they don't do realtime at small periods -- below a few ms. This is why NI and other vendors sell add-in products that plug into the PC. NI doesn't have much of a DSP offering, but instead offers a variety of products from plug-in boards with another micro, cRIOs, PXI, and other RIO products that instead offload to an FPGA for even lower periods and lower jitter.

Different from the timing, I was also going to point out that the loop you uploaded does lots of memory allocation and additional calculations inside the loop. It accumulates the slider value to the end of a growing buffer, reverses the buffer, filters the buffer into another growing buffer, reverses that buffer. Sending the entire buffer to a graph rather than just new points to a chart also causes extra overhead. Finally, the coefficients for the filter are being computed each time as well. The real issue is the timing source for scheduling, but when you start running on a realtime target, you don't want to resize a 10,000 point double precision array 2000 times a second.

I hope this answers some of your questions.
Greg McKaskle