Timing
Understand how the driver handles timing.
The Synnax driver uses a mixture of mechanisms to ensure that timestamps for acquired samples are as accurate as possible.
Most Recent Samples Over All Samples
The Synnax driver is used for low-latency control. For this reason, the driver will always prefer collecting the most recent samples over collecting all samples. This is particularly relevant when collecting samples from devices whose communication mechanisms fluctuate or can be unstable (i.e. USB).
Under heavy load, the driver will intentionally drop samples in order to keep up with the acquisition rate of the device.
Hardware Timed Tasks
Where possible, the driver will leverage sample clocks on the hardware data acquisition module itself to provide the most accurate timestamps possible. In hardware-timed mode, the driver uses the clock rate of the module to interpolate the time difference between samples.
Hardware timing is used for LabJack Read Tasks and NI Analog Read Tasks.
For example, we have a task with a sample rate of 100 Hz, and a stream rate of 10 Hz. This means that we’ll acquire 10 samples on every read from the module. Assuming that we started the task at absolute time 0, this is what the timestamps would look like:
| Sample Index | Time (s) | Notes |
|---|---|---|
| 0 | 0.000 | First sample of first read |
| 1 | 0.010 | |
| 2 | 0.020 | |
| 3 | 0.030 | |
| 4 | 0.040 | |
| 5 | 0.050 | |
| 6 | 0.060 | |
| 7 | 0.070 | |
| 8 | 0.080 | |
| 9 | 0.090 | Last sample of first read |
| 10 | 0.100 | First sample of second read |
| … | … | … |
| 19 | 0.190 | Last sample of second read |
| 20 | 0.200 | First sample of third read |
Skew Correction
While assuming that timestamps are evenly distributed is a very good approximation, the reality is that acquisition rates may fluctuate over time. This can happen for several reasons:
- The driver runs on a non-real-time operating system, meaning that individual acquisition loops may take longer or shorter than the specified stream rate.
- Minor differences between the hardware sample clock and the specified sample rate may cause accumulated errors over time.
- Unreliability in the data transport mechanism or heavy system load may cause the driver or transport mechanism to skip samples.
These factors mean that clock drift may accumulate over time, causing the evenly distributed timestamps generated by the hardware clock to deviate from the system time of the host machine running the driver.
To correct for this, the driver implements a skew correction algorithm that periodically makes minor corrections to the spacing between samples in order to ensure that the timestamps accurately represent the time the samples were acquired, and that the acquisition task stays aligned with the system clock.
As an additional benefit, the skew correction algorithm also ensures that hardware timed tasks stay aligned with other software timed task running on the same driver. For example, valve timings generated by a software-timed digital write task will remain closely aligned with the hardware-timed samples from an analog input task.
Skew correction is enabled by default, but can be disabled by setting the correct_skew
option to false in the driver configuration file, setting --correct-skew=false on
the command line, or by setting the SYNNAX_DRIVER_CORRECT_SKEW environment variable
to false.
Software Timed Tasks
When hardware timing is not available, the driver will resort to using the system clock in order to generate timestamps. This is less accurate than hardware timing, as samples are timestamped when they are received by the driver, rather than when they are acquired the hardware.
Software timed clocks are used for NI Digital Write/Read Tasks, LabJack Write Tasks, and OPC-UA Read Tasks.