On 02/19/2014 10:24 PM, Yogi A. Patel wrote:
>> On 02/19/2014 03:17 AM, Yogi A. Patel wrote:
>>> On Feb 18, 2014, at 3:57 PM, Gilles Chanteperdrix
>>> <[email protected]> wrote:
>>>
>>>> On 02/18/2014 07:13 PM, Yogi A. Patel wrote:
>>>>> Sorry, answers below.
>>>>>
>>>>>> On Feb 18, 2014, at 10:57, Gilles Chanteperdrix
>>>>>> <[email protected]> wrote:
>>>>>>
>>>>>>> On 02/18/2014 04:39 PM, Yogi A. Patel wrote: Hi -
>>>>>>>
>>>>>>> I have patched Scientific Linux 6.5 (Linux kernel v
>>>>>>> 2.6.32.20) with
>>>>>>
>>>>>> 2.6.32 is very old.
>>>>>>
>>>>>>
>>>>>>> 1. I don't quite understand everything being printed out
>>>>>>> here, however I know that not having overruns is great -
>>>>>>> but I also know that the worst case latencies are not
>>>>>>> acceptable.
>>>>>>
>>>>>> In the example you show, the worst case latency is 11µs,
>>>>>> is this what you do not find acceptable? If this is indeed
>>>>>> what you find unacceptable, I am afraid there is little we
>>>>>> can do.
>>>>>
>>>>> (RTXI.org)
>>>>
>>>> Website looks broken.
>>>
>>> I just checked - it is up and running. I would be interested in
>>> hearing your input about ours architecture and ways to make it
>>> better. (http://www.rtxi.org/about-rtxi/architecture/)
>>
>> Indeed, I had a "script error", which is now gone.
>
> Glad it worked. Any comments/feedback you may have is
> appreciated/welcome.
>
>>
>>>> Probably not. It will get clock_gettime(CLOCK_HOST_REALTIME)
>>>> working though, that was the initial question. That said,
>>>> running your kernel with a different configuration could help.
>>>> For instance turning off CONFIG_SMP, CONFIG_FTRACE,
>>>> CONFIG_PREEMPT usually helps reducing latency.
>>>
>>> OK, I recompiled and reran these tests and have latencies in the
>>> 10-11us range, still.
>>>
>>> Question - when it says “option is not set” in the config lie,
>>> does that by default mean that option is set to “n”? Or should I
>>> be setting options to “=n” instead?
>>
>> Options have dependencies, which the configuration tool enforces,
>> so, editing the .config by hand is not recommended, you should use
>> the interactive tools instead (xconfig, or menuconfig for
>> instance).
>
> I used menuconfig to go back and disable those three options you
> mentioned. Latencies are still around 11us. Also, just realized that
> there is an error in my title - I’m not on Ubuntu - I’m on Scientific
> Linux.
The three options I mentioned were examples to show that worst case
latency depends on how the kernel is compiled.
>
> Side question - in the processor setting section, there is an option
> for “Preemption Model”. I believe I should set that to "Preemptible
> Kernel (low latency desktop)” but am unsure. Is that correct?
No, as I said, in my experience, turning CONFIG_PREEMPT off, setting it
to CONFIG_PREEMPT_NONE, results in shorter worst case latencies for Xenomai.
However, I suspect you are still looking at the results of the latency
test on an idle system, which, as I told you, is not the worst case
latency at all. To measure the worst case latency, you have to run the
latency test for several hours, under load.
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
