LabVIEW
How Can I tell what is the latency of NI USB-9263 using python
Solved!
I think the remark about Python needs some clarification. If you need real hard real-time you have to use a solution that employs the hardware timing circuitry on a board to do all the critical timing and then have a driver interface that can buffer data (with the help of onboard buffers on the hardware itself). If you have that the application itself is pretty unimportant and you can do it in Python too, not just C or LabVIEW.
If you need soft real-time where you want to have a guaranteed reaction within several tenths of milliseconds rather than microseconds, you can use a real-time system and drive the hardware through this, but the driver would need to provide low latency code paths for this to work.
On a system like Windows there is no guarantee at all, Windows can theoretically decide to reconfigure its hardware driver system for any reason and block the entire system for multiple seconds where no process and not even a device driver can put his shoes in between to snoop away some CPU resources. Windows decided that it needs to do this thing and locks the system and nobody else can get in between until Windows finds that it is safe again. Here any application is limited not just Python.
The difference between Python and LabVIEW or C is, that Python is interpreted. When you do single sample analog or digital acquisition or generation, each call into the driver has to go through a whole chain of driver levels, eventually switch to kernel mode to call the actual hardware driver and then return back with the result. That takes a lot of time (in terms of computer timing). For an application written in LabVIEW or C, this whole passing through these drivers is always very much dominant and the actual code execution in the program itself requires minimal time if not programmed as a Rube Goldberg piece. In Python, the code is normally not only interpreted but every variable is an object that needs to be accessed, verified, managed and handled properly. That will usually cause the Python code to run significantly slower than the exact same code construct in C or LabVIEW. So if you are doing single sample acquisition or signal generation, Python can be indeed significantly slower than the others. But unless you do that on a real-time system, the intrinsic non real-time characteristics of the OS, make this mostly a moot point anyways, as you can not guarantee that such a single sample acquisition/generation is actually performed with a certain interval. Changes are higher if you use a programming languages that is fully compiled and with compile time variable typing, but it's not 100% ever.
