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
Re: [Xenomai] Question on rt_timer_tsc() vs rt_timer_read() semantics
Michael Haberler wrote: > 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 With the RTDM API, what you implement is a driver, so, the communication with user-space happens through the standard open/read/write/ioctl services. So, for instance, to get user-space to wait for a semaphore, you would implement a read or ioctl method in your driver which waits for an RTDM event. In the same vein, rtdm_mmap_to_user is meant to be used in the implementation of a driver ioctl. -- 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: > > 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 Actually, for kernel-space, you do not need xeno-config. > > 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. 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
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
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
Michael Haberler wrote: > I should have also noted the following: > > this is a 3.2.21 kernel homegrown like so: > http://git.mah.priv.at/gitweb/linuxcnc-kernel.git/shortlog/refs/heads/linuxcnc-3.2.21-xenomai-x86 > > I just see the ipipe tracer is for 2.6x only; I had dropped the 2.6 line > because of a module unloading issue but if that's the only option I'll > pick up the 2.6.38.8 kernel again and go from there The I-pipe tracer is available for 3.2 as well. -- 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
I should have also noted the following: this is a 3.2.21 kernel homegrown like so: http://git.mah.priv.at/gitweb/linuxcnc-kernel.git/shortlog/refs/heads/linuxcnc-3.2.21-xenomai-x86 I just see the ipipe tracer is for 2.6x only; I had dropped the 2.6 line because of a module unloading issue but if that's the only option I'll pick up the 2.6.38.8 kernel again and go from there - 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 >> ... > ___ 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: > 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
[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
