Re: [Xenomai-help] Time for rt_mutex_acquire

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

Dirk Eibach wrote:
> gilles.chanteperdrix@xenomai.org wrote:
>> On 8/17/07, Dirk Eibach <eibach@domain.hid> wrote:
>>> gilles.chanteperdrix@xenomai.org wrote:
>>>> Dirk Eibach wrote:
>>>>  > Hello,
>>>>  >
>>>>  > I'm wondering how long a rt_mutex_acquire is supposed to take on a PPC405
>>>>  > platform. I'm getting times about 50 usec here, which is too much for my
>>>>  > application. Is anything wrong in my kernel/xenomai configuration or is
>>>>  > this time to expected?
>>>>
>>>> How do you measure this ? Are you sure the mutex is free when you try to
>>>> acquire it ?
>>>>
>>> I prepared a small testcase. It shows about 8.300 ticks, which is about 30
>>> usec on my platform (266MHz).
>> Did you try to call ppc_getcounter twice in a raw to measure the
>> overhead of this function ?
> 
> Calling ppc_getcounter twice in a raw results in 116 ticks.

Is that service RT-safe, means does it stay in user space and issue no
Linux syscall? Maybe some of the PPC gurus can comment on this as well
(/me is lacking comparative numbers).

Besides this, you may want to try running the latency tracer on your
scenario. xntrace_user_start() and xntrace_user_stop(0) would frame the
path you want to measure, /proc/ipipe/trace/frozen will show its kernel
side. For sure, that tool will increase the latency even more, but it
may show better what goes on.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]