On Thu, 2011-09-08 at 12:06 +0200, Gilles Chanteperdrix wrote:
> On 09/08/2011 11:30 AM, Andrey Nechypurenko wrote:
> >> If I understand correctly, the difference is that Bob proposes you to
> >> dedicate a hardware timer to the PWM, whereas I propose you to use the
> >> software timers, which ultimately, also depend on a dmtimer. I would not
> >> expect big differences between the two approaches, neither in terms of
> >> jitter, nor in terms of code.
> >
> > I see. Thanks for the explanations.
> >
> >> As suggested in the previous mail I sent you, compare the differences in
> >> latencies with latency -t 2 between user-space task and kernel-space
> >> timer. You will see that a timer handler has much less jitter.
> >
> > It is clear for me that there is a difference. I am trying to
> > understand what is the reason for the difference. I thought that as
> > soon as Xenomai task is created (does not matter from user or kernel
> > space) it is managed by Xenomai in the similar way and correspondingly
> > the results should be also similar (which is obviously no the case).
>
> xenomai provides user-space threads and kernel-space threads, which work
> much like linux user-space and kernel-space threads.
>
> >
> >> Switch to user-space, and context switch time explain the difference.
> >
> > So is it the only reason for the differences or there are some other
> > factors influencing the results?
>
> It is the only reason.
>
> With latency -t 2. As soon as the timer interrupt happens, the timer
> handler, which runs in irq context, measures the jitter.
>
> With latency -t 0. When the timer interrupt happens, we need to switch
> to the kernel-space task associated with the user-space sampling task,
^^^
You meant stack, I guess.
> in the worst case, the currently running task was not in the same memory
> space, so, a switch of the mmu context is needed. Then we need to return
> to user-space, as a return to the "rt_task_wait_period" syscall at which
> point the jitter is measured.
Add to this the opportunity for a real-time IRQ to preempt the task on
its way back to userland, delaying the measurement from the time spent
to run the ISR (at the very least).
>
> All this involves longer code paths and greater opportunities for cache
> effects.
>
> This difference between kernel-space and user-space explains why we
> advise people to split their application between application and driver,
> the really critical part using the RTDM skin, in kernel-space, much like
> you would do with linux.
>
--
Philippe.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
