On 5 April 2018 21:19, quoth Michael Ruder: > In fact, the function that takes the long time is ecrt_domain_process (and > not ecrt_domain_queue). However, if I do no longer the call to > ecrt_domain_queue, then the ecrt_domain_process will not take long (that > is what got me on the wrong track yesterday).
If you don't queue the domain datagram then there's nothing to process, so that makes sense. 😊 It's peculiar for ecrt_domain_queue or ecrt_domain_process to take all that long, however. Even with a large network with a complicated PDO layout I've never seen these take very long. Have you issued an mlockall at the start of your process? It can also help to explicitly prefault your stack so that you don't get a page fault later if your stack depth grows. I have had issues in the past where ecrt_master_receive took unexpectedly long; the culprit was the e1000e network driver, which during the poll sometimes triggered watchdog processing directly on that thread instead of on a background thread. There's some patches in the unofficial patchset (http://sourceforge.net/u/uecasm/etherlab-patches/ci/default/tree/#readme) to resolve the cases that were encountered there, among other things. > This only happens on my Yocto system but not on a Gentoo system with the > identical kernel (4.14.28-rt23). On the Gentoo, the calls never take long, > even > during transitions. What network driver and hardware are you using? _______________________________________________ etherlab-users mailing list [email protected] http://lists.etherlab.org/mailman/listinfo/etherlab-users
