#linuxcnc-devel Logs

Sep 16 2021

03:30 AM rs[m]: fdarling: ar is posted yesterday on #linuxcnc, this https://github.com/LinuxCNC/linuxcnc/blob/master/src/rtapi/uspace_rtapi_app.cc#L1112 is the waiting part of the main loop. look at the Posix object for other implementation details.
03:36 AM rs[m]: fdarling: if in your app you get excessive jitter compared to linuxcnc, check your thread scheduling policy. also binding to a specific cpu core may make a difference.
03:36 AM rs[m]: caveat emptor
08:42 AM -!- #linuxcnc-devel mode set to +v by ChanServ
11:09 AM fdarling: rs[m]: I found something even more strange: my jitter is the same as LinuxCNC's if I have LinuxCNC's latency test open while I run my program. If I run my program without the latency test, I go back to my original numbers. It seems that LinuxCNC is changing something globally while it's running...
11:10 AM fdarling: I am using the same algorithm to select a CPU to bind to, similar to what LinuxCNC does, so that's not the issue
12:02 PM pcw_home: Is it possibly the dma_latency settings?
12:06 PM fdarling: pcw_home: I am running my test program on the exact same computer as LinuxCNC, the behavioral difference is whether or not LinuxCNC is actually open (in the form of the latency test)
12:06 PM fdarling: I don't see how any DMA settings in the BIOS would affect this
12:07 PM pcw_home: in an OS setting
12:09 PM pcw_home: #ifdef __linux__
12:09 PM pcw_home: int fd = open("/dev/cpu_dma_latency", O_WRONLY | O_CLOEXEC);
12:09 PM pcw_home: if (fd < 0) {
12:09 PM pcw_home: rtapi_print_msg(RTAPI_MSG_WARN, "failed to open /dev/cpu_dma_latency: %s\n", strerror(errno));
12:09 PM pcw_home: } else {
12:09 PM pcw_home: int r;
12:09 PM pcw_home: r = write(fd, "\0\0\0\0", 4);
12:09 PM pcw_home: if (r != 4) {
12:09 PM pcw_home: rtapi_print_msg(RTAPI_MSG_WARN, "failed to write to /dev/cpu_dma_latency: %s\n", strerror(errno));
12:09 PM pcw_home: }
12:09 PM pcw_home: // deliberately leak fd until program exit
12:09 PM pcw_home: }
12:09 PM pcw_home: #endif /* __linux__ */
12:10 PM pcw_home: return 0;
12:12 PM fdarling: thanks, I will try that, it does look like it's modifying a global setting which could be the key
12:27 PM pcw_home: there may be others (that was from uspace_rtapi_app.cc )
12:32 PM rs[m]: fdarling: you are sure your thread scheduling priority is SCHED_FIFO? you can check and manipulate stuff with "taskset" command
12:33 PM fdarling: yes, I am using the same code as in LinuxCNC, which is also from a PREEMPT_RT example online
12:33 PM fdarling: however I am not doing the harden_rt() stuff that LinuxCNC is doing, like the DMA and setting some priority ceiling and stuff
01:09 PM fdarling: pcw_home: so it was definitely the DMA trick! :-) thank you so much!
03:07 PM Eric_ is now known as unterhausen
03:57 PM Tom_itx is now known as Tom_L