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

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

[xenophile]

On 05/29/12 21:52, Gilles Chanteperdrix wrote:
> On 05/29/2012 09:50 PM, xenophile wrote:
>> On 05/29/12 21:41, xenomai-owner@xenomai.org wrote:
>>>
>>> On 05/29/12 16:43, Philippe Gerum wrote:
>>>>
>>>> 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.
>>>>
>>>
>>
>> So what would be the best kind of x86 hardware to use for RT?
>>
>>    Hyperthreading comes with multicore processors I think.
>>
>>    What systems least SMI code ?
>>
>>    My guess is that fast 32 bit x86 hardware like top of range AMD Athlon
>>    processors would be good (better than multicore 64 bit ) but I'm only
>>    guessing.
>>
>>    Are fast graphics cards better, so long as they can be run without
>>    proprietary drivers ?
>>
>>    I'm sure there's no hard and fast answer but can you offer any guide
>> lines?
>>
>>    Thx.
>
> The address of the mailing list is xenomai@xenomai.org, not
> xenomai-owner@xenomai.org
>

Sorry,  I got a bounce because I originally sent the msg from the wrong 
email account my end  (that bounce came from "owner").

I replied to the bounce with the correct sender,  thinking it would go 
to the list , I did not notice that it was from xenomai-owner.

So hopefully both sender and recipient are now correct and this will 
appear on the list.

Phew.

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

[Gilles Chanteperdrix]

On 05/29/2012 02:54 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...)
> 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?
> Any answer will be much appreciated.
> Is it OK to ask such general questions in this mailing list or i
> should use the other mailing list, xenomai@xenomai.org?
> Thank you Mr. Chanteperdrix to answer my previous question.

There is no such time limit. A task is executed as long as it does not
suspend or yield and there is no other task with higher priority.

Please note: the mailing list address changed, it is now xenomai@xenomai.org

-- 
					    Gilles.

[Xenomai] What is the Xenomai time limit?

[ali hagigat]

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...)
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?
Any answer will be much appreciated.

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

[Philippe Gerum]

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.
>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai
>


-- 
Philippe.

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

[ali hagigat]

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.

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?

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.
>>

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

[Philippe Gerum]

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.