Preemptive operating systems, such as Windows, do not provide the determinism that an embedded (real-time) system does, so even a timed loop will not execute deterministically on Windows. It will, however, still execute with a higher priority than normal LabVIEW loops in an attempt to achieve the configured timing, but it is at the mercy of the operating system scheduler. Also, be aware that there is a hardware limitation with the Windows clock. Tick counts are obtained from the system BIOS, but only provide 1 ms resolution (so MHz clocks can not be implemented on non real-time systems) on Windows systems. Date / time functions (such as the Get Date/Time in Seconds VI) obtain their values from the Windows calendar, which is updated only at 60 Hz, and so updates every ~16.7 ms. Despite the fact that your desktop PC may have a CPU with a clock rate in the GHz, you don't have access to the raw hardware clock to time code execution. As you are attempting to time your code at 1 ms, you are at the very upper end of what is possible on a non real-time system, and a timed loop in LabVIEW will try to achieve it, but will almost certainly be preempted at some point, resulting in late / missed iterations.
The acquisition rates of your DAQ device are possible through the use of buffering, so you can get lossless data streaming at high rates (high throughput) by accepting processing overhead (increased latency). The way to address this in your application is to similarly run your processing on buffered data sets, increasing the batch size until your batch processing can iterate quickly enough to process all of the incoming data and still have some CPU cycles left over to cede to other processes.
