Re: [Xenomai] Decrease Latency (below 10 us) on x32 or x32_64?

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 03/28/2013 02:04 PM, Manuel Huber wrote:

> On 2013-03-28 13:46, Gilles Chanteperdrix wrote:
>> On 03/28/2013 11:06 AM, Manuel Huber wrote:
>>
>>> On 2013-03-26 12:57, Gilles Chanteperdrix wrote:
>>>> On 03/26/2013 11:18 AM, Manuel Huber wrote:
>>>>
>>>>> Hello!
>>>>>
>>>>> Sorry for the delay. I have re-compiled the Kernel with the I-pipe
>>>>> tracer enabled, and I disabled the HPET. Then, I tried to reset the
>>>>> tracer by writing 0 to /proc/ipipe/trace/frozen and some string to
>>>>> /proc/ipipe/trace/max. Then I started the latency program with the -f
>>>>> option for some minutes and afterwards captured the variables in
>>>>> /proc/ipipe/trace/. One test has been made in single-user mode and
>>>>> without the nouveau driver (plain-vga_300.txt) and the other trace has
>>>>> been made in normal multi-user mode with gdm running (and the nouveau
>>>>> driver; gui_300.txt). There is one trace without any USB-device
>>>>> attached (plain-vga_300_no_usb.txt), but I'm not sure if that makes
>>>>> any difference.
>>>>>
>>>>> I hope I used the I-pipe tracer correctly. I'm sorry to bother you
>>>>> again, but I can't interpret the results :( Maybe you could interpret
>>>>> the trace, if you have time for it...
>>>> The traces are too short. Try:
>>>> echo 1000 > /proc/ipipe/trace/back_trace_points
>>>>
>>>> There should be at least a "tick@" trace indicating the time when the
>>>> timer was supposed to tick and when it did not, so that we have an idea
>>>> of the latency.
>>>>
>>>> What is the period you use for the latency test?
>>>>
>>> Hello!
>>>
>>> Sorry, I have run the same tests again, just with back_trace_points
>>> set to 1000. I've run the latency tool for 5 minutes with a period of
>>> 100 us (default).
>>
>> Well, there is only one strange spot:
>> :|  # func                 -31	  0.324  ipipe_timer_set+0x9 (xntimer_next_local_shot+0xc4)
>> :|  # func                 -31+   8.732  lapic_next_event+0x3 (ipipe_timer_set+0x77)
>> :|  # func                 -22+   3.484  __xnpod_schedule+0x9 (xnintr_clock_handler+0x124)
>> :|  # func                 -19+   5.443  __xnlock_spin+0x9 (T.1349+0x55)
>> :|  # [ 1996] Xorg    -1   -13	  0.211  __xnpod_schedule+0x69 (xnintr_clock_handler+0x124)
>>
>> Which would indicate that maybe the bus is busy with another core.
>> But strangely the latency is around 36us as measure with the other traces.
>>  From your traces, I do not see anything pathological.
>>
>>> I don't think it's related, but xeno-test fails on the machine, and I
>>> think it's because of CONFIG_XENO_OPT_SYS_HEAPSZ. I have multiplied it
>>> with a factor of 6 (as described here:
>>> http://osdir.com/ml/linux.real-time.xenomai.users/2007-03/msg00251.html).
>>
>> And the error message is...?
>>
> Hello!
> 
>>  From your traces, I do not see anything pathological.
> Would you expect the timing to be better with a 64bit-Kernel? Could
> it be related to memory management overhead of the Kernel...


You would probably have better latencies with using Xenomai on only one 
core. But 36us with the tracer on does not look so bad, does it?

Did you try the configuration options I gave in the answer to your 
first mail?

> 
>> And the error message is...?
> Oh, sorry; The message was:
> ioctl(RTTST_RTIOC_SWTEST_CREATE_KTASK): Cannot allocate memory
> I multiplied CONFIG_XENO_OPT_SYS_HEAPSZ and CONFIG_XENO_OPT_SYS_STACKPOOLSZ
> each by a factor of 6. The resulting values are:
> CONFIG_XENO_OPT_SYS_HEAPSZ = 1536
> CONFIG_XENO_OPT_SYS_STACKPOOLSZ = 768
> 
> I got the info from an old posting you wrote and it fixed the
> problem as expected.


This is also documented in the TROUBLESHOOTING guide:
http://www.xenomai.org/documentation/xenomai-2.6/html/TROUBLESHOOTING/#_switchtest_fails_with_pthread_create_resource_temporarily_unavailable

-- 
                                                                Gilles.