From: Philippe Gerum <rpm@xenomai.org>
To: ali hagigat <hagigatali@gmail.com>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai] What is the Xenomai time limit?
Date: Tue, 29 May 2012 16:43:18 +0200 [thread overview]
Message-ID: <4FC4E086.8090702@xenomai.org> (raw)
In-Reply-To: <CAKKWdtcDaTBSc5mr1MWEhvDyx45r-D-2rOxA_BE+aVdR595GaA@mail.gmail.com>
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.
next prev parent reply other threads:[~2012-05-29 14:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-29 12:38 [Xenomai] What is the Xenomai time limit? ali hagigat
2012-05-29 14:43 ` Philippe Gerum [this message]
2012-05-30 13:39 ` ali hagigat
2012-05-30 14:49 ` Philippe Gerum
[not found] <CAKKWdtfO26_v+gQnMnu9_dkWMMQ3D7WCB_PxXa6tsSYNFEnBdQ@mail.gmail.com>
2012-05-29 13:14 ` Gilles Chanteperdrix
[not found] <mailman.0.1338320469.1537.xenomai@xenomai.org>
[not found] ` <4FC52889.8050002@piments.com>
[not found] ` <4FC528F0.2070307@xenomai.org>
2012-05-29 20:00 ` xenophile
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FC4E086.8090702@xenomai.org \
--to=rpm@xenomai.org \
--cc=hagigatali@gmail.com \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.