Re: [Xenomai] What is the Xenomai time limit?

[Philippe Gerum <rpm@xenomai.org>]

On 05/30/2012 03:39 PM, ali hagigat wrote:
> Dear Philippe,
>
> Much appreciate for the reply.
>
> Latency test seems to give some statistics about the system at the
> time of the test.
>
> I was looking for an exact maximum time so that scheduling latency is
> always below that time.

See "lat worst" column of that test, after a significant run time under 
meaningful load. This system offers experimental values, nothing more.

>
> I figured it out that even adding a new hardware may effect the
> maximum scheduling latency. Is that true? If I add a new hardware and
> its driver, it can mask the interrupts for example. Can it make the
> xenomai system non real-time?

It's unlikely that a driver by itself would introduce latency unless it 
deliberately attempts to bypass the interrupt virtualization mechanism 
implemented by Xenomai, and does it wrongly.

Generally speaking, a real-time system is in essence a specific 
combination of hw and sw which happen to cope well together with respect 
to meeting deadlines, so I don't believe there is a definite answer to 
your question. In theory, that answer would be yes. In practice, this 
happens rarely.

>
> Regards
>
>> On 05/29/2012 02:38 PM, ali hagigat wrote:
>>>
>>> We know that Xenomai can create hard real time tasks and it means that
>>> the real time tasks will be executed up to a specific time. My
>>> question is about that time. How much is that time?(100 micro seconds,
>>> 150 usec, or...)
>>
>>
>> Do you mean maximum latency? If so, you only have to run the "latency" test
>> program on your board (/usr/xenomai/bin/latency for a default install).
>>
>> With modern hardware, 100 us on x86 is considered a bug.
>>
>>
>>> I know that it may depend on the architecture and the software platform.
>>> I want to know how can i determine that time for my x86 32-bit PC
>>> system? and besides what major factors are effecting the time?
>>
>>
>> Assuming time == latency, major arch-independent factors include bus
>> locking, MMU handling (e.g. see issues with VIVT caches on ARM), cache
>> artifacts caused by concurrent linux activity in general (which may cause
>> real-time code to be evicted during idle phases by non-rt code).
>>
>> x86-wise, there is some more issues to keep an eye on:
>>
>> - Hyperthreading (not nice to -rt requirements)
>> - SMI sources (causing IRQ-disabling BIOS code to be invoked directly by
>> special interrupts not going through the programmable interrupt controller,
>> so we can't block them, and don't know when they happen).
>> - Some graphic card adapters (causing hw stalls to favor their own
>> throughput)
>> - Some graphic card drivers, most often proprietary, disabling interrupts
>> for too long.
>> - Some cycle-hungry x86 cache invalidation instructions (wbinv).
>> - The legacy x86 PIT (i8254) when used, which goes through a legacy ISA bus,
>> as expensive as ~1.5-2.5 us for each I/O access (you need at least two of
>> them to program the next clock tick). Fortunately, you won't need it on a
>> modern x86 platform, unless really unlucky.
>>
>> Oh well, other that that, x86 is almost fine for -rt stuff.
>>
>>> Any answer will be much appreciated.
>>>
>


-- 
Philippe.