[Xenomai] Question on rt_timer_tsc() vs rt_timer_read() semantics
I'm porting the LinuxCNC realtime support to Xenomai, and that has its own latency-test program. I observe: - the xenomai latency test is generally acceptable - with the LinuxCNC latency-test program I see occasional spikes up to maybe 80-100uS the only difference in the code I could discern is: the xenomai src/testsuite/latency/latency.c code uses rt_timer_tsc() to read the timestamp my port currently uses rt_timer_read() the question is: a) did I commit a blunder and should just change rt_timer_read() to use rt_timer_tsc() and all be fine, because that could be the explanation for the spike b) should I look elsewhere for the cause? thanks in advance, Michael ps: looks like a bit of a Heisenspike to me: if I simultaneously run *both* latency tests, I dont see the spike (which of course doesnt prove it wont come eventually :-/) ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Question on rt_timer_tsc() vs rt_timer_read() semantics
Michael Haberler wrote: I'm porting the LinuxCNC realtime support to Xenomai, and that has its own latency-test program. I observe: - the xenomai latency test is generally acceptable - with the LinuxCNC latency-test program I see occasional spikes up to maybe 80-100uS the only difference in the code I could discern is: the xenomai src/testsuite/latency/latency.c code uses rt_timer_tsc() to read the timestamp my port currently uses rt_timer_read() the question is: a) did I commit a blunder and should just change rt_timer_read() to use rt_timer_tsc() and all be fine, because that could be the explanation for the spike Using rt_timer_read() instead of rt_timer_tsc() is probably not the cause for the spike. The difference between rt_timer_read() and rt_timer_tsc() is that on most platforms, rt_timer_tsc() is implemented without a system call, so the measured latencies is closer to reality (and smaller). b) should I look elsewhere for the cause? Yes. Two things you can do: - show us the code of your latency test so that we can have a look at it for obvious mistakes - enable the I-pipe tracer in the kernel configuration and trigger a trace freeze (like latency -f option) when you hit the spike. http://www.xenomai.org/index.php/I-pipe:Tracer Also note that if LinuxCNC code runs in kernel-space, you should not be using the native API, but the RTDM API. -- Gilles. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Question on rt_timer_tsc() vs rt_timer_read() semantics
Gilles, thanks for the fast reply, I will look into the I-pipe tracer. as for the current code: yes, it uses the native API - I started with existing RTAI code and massaged that - but I'll rewrite it to RTDM if that's how it's supposed to be done. -- as for how the LinuxCNC latency-test works: It's a bit involved as lots of loadable kernel modules are involved which export named functions; these functions are then called in turn by the RT thread. The rough picture is this: - a new thread is created in rtapi_task_new here : http://git.mah.priv.at/gitweb/emc2-dev.git/blob/5979d84f31c0ef8e9dccdb26426732d0b83f3a87:/src/rtapi/xenomai_kernel_rtapi.c#l871 - it's actually started in rtapi_task_start here: http://git.mah.priv.at/gitweb/emc2-dev.git/blob/5979d84f31c0ef8e9dccdb26426732d0b83f3a87:/src/rtapi/xenomai_kernel_rtapi.c#l1021 - the code it executes is here: http://git.mah.priv.at/gitweb/emc2-dev.git/blob/5979d84f31c0ef8e9dccdb26426732d0b83f3a87:/src/hal/hal_lib.c#l2672 - this just runs through the LKM function chain and does an rtapi_wait at the end - rtapi_wait is rt_task_wait_period() with error reporting tacked on: http://git.mah.priv.at/gitweb/emc2-dev.git/blob/5979d84f31c0ef8e9dccdb26426732d0b83f3a87:/src/rtapi/xenomai_common.c#l78 -- so this is the basic plumbing; the actual latency test works like so: the threads module starts a thread through the mechanism outlined above : http://git.mah.priv.at/gitweb/emc2-dev.git/blob/5979d84f31c0ef8e9dccdb26426732d0b83f3a87:/scripts/latency-test#l58 (the actual code of the threads module is here, but it's a higher level API, so thats irrelevant: http://git.mah.priv.at/gitweb/emc2-dev.git/blob/5979d84f31c0ef8e9dccdb26426732d0b83f3a87:/src/hal/components/threads.c) - the timedelta module just samples with rtapi_get_time(): http://git.mah.priv.at/gitweb/emc2-dev.git/blob/5979d84f31c0ef8e9dccdb26426732d0b83f3a87:/src/hal/components/timedelta.comp (this _is_ a kernel module, it's in preprocessor language). rtapi_get_time() in turn calls rt_timer_read() here: http://git.mah.priv.at/gitweb/emc2-dev.git/blob/5979d84f31c0ef8e9dccdb26426732d0b83f3a87:/src/rtapi/xenomai_kernel_rtapi.c#l657 whew, I think I covered it. Is this still comprehensible ;-? best regards, Michael Am 03.11.2012 um 10:37 schrieb Gilles Chanteperdrix: Michael Haberler wrote: I'm porting the LinuxCNC realtime support to Xenomai, and that has its own latency-test program. I observe: - the xenomai latency test is generally acceptable - with the LinuxCNC latency-test program I see occasional spikes up to maybe 80-100uS the only difference in the code I could discern is: the xenomai src/testsuite/latency/latency.c code uses rt_timer_tsc() to read the timestamp my port currently uses rt_timer_read() the question is: a) did I commit a blunder and should just change rt_timer_read() to use rt_timer_tsc() and all be fine, because that could be the explanation for the spike Using rt_timer_read() instead of rt_timer_tsc() is probably not the cause for the spike. The difference between rt_timer_read() and rt_timer_tsc() is that on most platforms, rt_timer_tsc() is implemented without a system call, so the measured latencies is closer to reality (and smaller). b) should I look elsewhere for the cause? Yes. Two things you can do: - show us the code of your latency test so that we can have a look at it for obvious mistakes - enable the I-pipe tracer in the kernel configuration and trigger a trace freeze (like latency -f option) when you hit the spike. http://www.xenomai.org/index.php/I-pipe:Tracer Also note that if LinuxCNC code runs in kernel-space, you should not be using the native API, but the RTDM API. -- Gilles. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Question on rt_timer_tsc() vs rt_timer_read() semantics
Michael Haberler wrote: - the timedelta module just samples with rtapi_get_time(): http://git.mah.priv.at/gitweb/emc2-dev.git/blob/5979d84f31c0ef8e9dccdb26426732d0b83f3a87:/src/hal/components/timedelta.comp (this _is_ a kernel module, it's in preprocessor language). rtapi_get_time() in turn calls rt_timer_read() here: http://git.mah.priv.at/gitweb/emc2-dev.git/blob/5979d84f31c0ef8e9dccdb26426732d0b83f3a87:/src/rtapi/xenomai_kernel_rtapi.c#l657 whew, I think I covered it. Is this still comprehensible ;-? That is a lot to check, so, I am afraid it will be hard to be of any help, the tracer is probably your only hope. Just a minor nit though, if you intend to run LinuxCNC on anything else than x86, you should replace rdtscll with rt_timer_tsc or __xn_rdtsc. -- Gilles. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Question on rt_timer_tsc() vs rt_timer_read() semantics
Gilles, Am 03.11.2012 um 10:37 schrieb Gilles Chanteperdrix: http://www.xenomai.org/index.php/I-pipe:Tracer thanks for the version hint - it was all in place, just needed to configure - building now. Also note that if LinuxCNC code runs in kernel-space, you should not be using the native API, but the RTDM API. I missed out that fineprint in the roadmap.. yes, these are kernel-space threads reading through the examples it occurs to me adapting to RTDM pretty much only involves changing includes, the --skin=rtdm argument to xeno-config, and changing the native rt_* calls to the next best rtdm_* calls that's all, and I'll be happy ever after even after the merge with RT_PREEMPT ;-? - Michael ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] Question on rt_timer_tsc() vs rt_timer_read() semantics
sorry to be a pain.. that's all, and I'll be happy ever after even after the merge with RT_PREEMPT ;-? Yes, that is the point, the port of RTDM over the Linux kernel API already exists, though AFAIK it is not merged yet in the xenomai-forge tree. porting native-RTDM: mapping the task and timer RTDM API is fairly clear to me the fuzzy part: I need shared memory segments and semaphores allocated in kernel space which eventually are picked up in/used from userland between kernel and user process so far I used the rt_heap API for shm, and rt_sem_create/rt_sem_delete/rt_sem_p/rt_sem_v, which worked fine I'm completely at loss how to make that work with rtdm_sem* and rtdm_mmap_to_user any decent examples or hints how to do this? the examples in the xenomai tree dont help me with that - Michael Another option for your case would be to implement the rtapi_ services as a Xenomai skin, but in that case you would have some work when merging with PREEMPT_RT. -- Gilles. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
