[x] Suggestion: Would calling clock_nanosleep just before ecrt_master_send reduce jitter?
Additional Details
By calling clock_nanosleep before ecrt_master_receive (the current order) we ensure that the datagrams are received (ecrt_master_receive) every 1 ms.
We assume we send the datagrams (ecrt_send_master) every 1 ms. This assumption is valid only if what comes before ecrt_send_master (and after clock_nanosleep) takes the same amount of time every cycle. This includes ecrt_master_receive , ecrt_domain_process ,ecrt_domain_queue, distributed clock function calls, and any additional processing. But there's no guarantee that those function themselves are jitter-free. The functions' jitter can be measured (similar to what's done by uncommenting MEASURE_PERF) and logged.
Result
no-stress test: although the worst-case jitter didn't change (still about 37 microseconds. At this point I'd say it's probably hardware-related), the update rate vs. time graph looks much cleaner. Additionally, five-sigma jitter is reduced to 1.4 microseconds.
See commit aaa2445251c52263d0d44b2f44b14953c649d60c.
[ ] Suggestion: Add a userspace thread to main.c for inserting data into the queue when the main thread is sleeping (i.e. when clock_nanosleep is called).
Additional Details
The thread should have a somewhat lower FIFO priority (for instance 80). The code in the main thread can give a signal to the queue thread (e.g. by setting variable flag, or a mutex) exactly before it calls clock_nanosleep. Variables that are to be inserted into the queue can be global.
clock_nanosleep
just beforeecrt_master_send
reduce jitter?Additional Details By calling
clock_nanosleep
beforeecrt_master_receive
(the current order) we ensure that the datagrams are received (ecrt_master_receive
) every 1 ms.We assume we send the datagrams (
ecrt_send_master
) every 1 ms. This assumption is valid only if what comes beforeecrt_send_master
(and afterclock_nanosleep
) takes the same amount of time every cycle. This includesecrt_master_receive
,ecrt_domain_process
,ecrt_domain_queue
, distributed clock function calls, and any additional processing. But there's no guarantee that those function themselves are jitter-free. The functions' jitter can be measured (similar to what's done by uncommenting MEASURE_PERF) and logged.Result no-stress test: although the worst-case jitter didn't change (still about 37 microseconds. At this point I'd say it's probably hardware-related), the update rate vs. time graph looks much cleaner. Additionally, five-sigma jitter is reduced to 1.4 microseconds.
See commit aaa2445251c52263d0d44b2f44b14953c649d60c.
main.c
for inserting data into the queue when the main thread is sleeping (i.e. whenclock_nanosleep
is called).Additional Details The thread should have a somewhat lower FIFO priority (for instance 80). The code in the main thread can give a signal to the queue thread (e.g. by setting variable
flag
, or a mutex) exactly before it callsclock_nanosleep
. Variables that are to be inserted into the queue can be global.Result