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.
> and the latencies
> used to be single digits (5-8us). I am comparing against those values
> and thought my configuration may not be adequate.
Some words about latencies:
- the worst case latency for one machine is not the same as for the
next, there are various factors at work which can cause jitter, such as
cache size, DDR speed, so code size and code "density" have an
influence, in other words, linux version and linux configuration have an
influence.
- in the case of RTAI and Xenomai, the setting you choose for timer
anticipation (/proc/xenomai/latency) also has an influence;
- as the name "worst case latency" implies, the worst case latency is
not a figure you will see by running the latency test for a few seconds,
in order to have any confidence into the worst case returned by the
latency test, you must run the latency test with the machine under load
for some time (a few hours will do). We provide the xeno-test and dohell
scripts to help you do that.
> If this is the norm for xenomai, no problem.
There is no norm for xenomai, as the actual figure depends on a lot of
parameters.
>
> What is the big difference between RTAI and Xenomai? I don't
> understand the difference between the two systems well enough, I
> suppose.
See the FAQ.
>
>>>
>>> 2. I read that the SMI-enabled chipsets can cause latency issues.
>>> I added "xeno_hal.smi=1" to the kernel boot arguments, however I
>>> got an error saying "SMI workaroudn failed" when I rebooted into
>>> the kernel. I believe I have a BIOS that can't change the bit for
>>> the SMI. Not sure what else to do here.
>>
>> SMI cause problems when they cause latencies above, say 80us. A
>> latency of 10us is something normal.
>
> Ok this is good to know.
>
>>
>>>
>>> 3. I'm not sure if the following two lines are causing the error
>>> (primarily because I don't know what they mean):
>>>
>>> clock_gettime failed for clock id 42 XNVDSO_FEAT_HOST_REALTIME
>>> not available
>>
>> No, they simply mean that you are using a too old kernel.
>
> Would upgrading the kernel version make a significant impact on
> latency?
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.
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
