[Xenomai-help] High resolution timers disabled on AT91SAM9G20 board after patching

[Xenomai-help] High resolution timers disabled on AT91SAM9G20 board after patching

[at91_enthus]

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]

Hi!

I installed the latest xenomai patch on a AT91SAM9G20 board and everything
looked good at a first glance: no compilation problems, low latencies.

However, when I typed cat /proc/timer_list , the resolutions in  cpu0 and
cpu1 items showed 100000 (ns).
(I compiled the Xenomai patched kernel with High Resolution Timers enabled.)

I don't have this problem when I boot a real time kernel (RT_PREEMPT).

One more thing. I also have a Beagleboard that runs a Xenomai patched kernel
and in this case the resolution for HRT shows 1 ns, as it should.

Thanks,
Razvan

[-- Attachment #2: Type: text/html, Size: 616 bytes --]

Re: [Xenomai-help] High resolution timers disabled on AT91SAM9G20 board after patching

[Gilles Chanteperdrix]

at91_enthus wrote:
> Hi!
> 
> I installed the latest xenomai patch on a AT91SAM9G20 board and
> everything looked good at a first glance: no compilation problems, low
> latencies.
> 
> However, when I typed cat /proc/timer_list , the resolutions in  cpu0
> and cpu1 items showed 100000 (ns).
> (I compiled the Xenomai patched kernel with High Resolution Timers enabled.)
> 
> I don't have this problem when I boot a real time kernel (RT_PREEMPT).

You mean another real-time kernel? If RT_PREEMPT uses the sys timer
running at 32kHz, and it tells you that it has a 1ns resolution, then it
is lying, because 32kHz, means a 30us resolution.

Xenomai uses one TC as a timer at whatever frequency your chip proposes
over 1 MHz, this means a resolution below 1us, the downside is that this
also means a very short wrap time. And since the TC is also used as a
clock, this means that we must enter the timer interrupt handler before
the counter wraps. And this is something that Linux without Xenomai
running can not guarantee.

Do you have this issue when running a Xenomai application?

Also note that if you use Xenomai timing services, you will not have
this issue, of course.

>
> One more thing. I also have a Beagleboard that runs a Xenomai patched
> kernel and in this case the resolution for HRT shows 1 ns, as it should.
>

If you read a bit more about the I-pipe patch for ARM, you will learn
that the timer implementation is specific to each SOC. So, comparing the
OMAP3530 to the AT91SAM9G20 is as much relevant as comparing the timer
of an X86 to the timer of a PowerPC.

-- 
                                                                Gilles.

Re: [Xenomai-help] High resolution timers disabled on AT91SAM9G20 board after patching

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
> at91_enthus wrote:
>> Hi!
>>
>> I installed the latest xenomai patch on a AT91SAM9G20 board and
>> everything looked good at a first glance: no compilation problems, low
>> latencies.
>>
>> However, when I typed cat /proc/timer_list , the resolutions in  cpu0
>> and cpu1 items showed 100000 (ns).
>> (I compiled the Xenomai patched kernel with High Resolution Timers enabled.)
>>
>> I don't have this problem when I boot a real time kernel (RT_PREEMPT).
> 
> You mean another real-time kernel? If RT_PREEMPT uses the sys timer
> running at 32kHz, and it tells you that it has a 1ns resolution, then it
> is lying, because 32kHz, means a 30us resolution.
> 
> Xenomai uses one TC as a timer at whatever frequency your chip proposes
> over 1 MHz, this means a resolution below 1us, the downside is that this
> also means a very short wrap time. And since the TC is also used as a
> clock, this means that we must enter the timer interrupt handler before
> the counter wraps. And this is something that Linux without Xenomai
> running can not guarantee.

On the other hand, we can keep the timer ticking behind Linux' back.
Does the following patch fix the issue for you?

diff --git a/arch/arm/mach-at91/at91_ipipe_time.c
b/arch/arm/mach-at91/at91_ipipe_time.c
index b0327eb..6c6f0d7 100644
--- a/arch/arm/mach-at91/at91_ipipe_time.c
+++ b/arch/arm/mach-at91/at91_ipipe_time.c
@@ -76,9 +76,7 @@
 #define TCNXCNS(timer,v) ((v) << ((timer)<<1))
 #define AT91_TC_REG_MASK (0xffff)

-static unsigned long next_match;
-
-static unsigned max_delta_ticks, min_delta_ticks;
+static unsigned max_delta_ticks, min_delta_ticks, tick_pending;
 static struct clock_event_device clkevt;
 static int tc_timer_clock;

@@ -116,7 +114,11 @@ EXPORT_SYMBOL(__ipipe_mach_ticks_per_jiffy);
  */
 static irqreturn_t at91_timer_interrupt(int irq, void *dev_id)
 {
-	clkevt.event_handler(&clkevt);
+	if (__ipipe_mach_timerstolen || tick_pending) {
+		tick_pending = 0;
+		clkevt.event_handler(&clkevt);
+	}
+
 	return IRQ_HANDLED;
 }

@@ -130,12 +132,8 @@ void __ipipe_mach_acktimer(void)
 {
 	at91_tc_read(AT91_TC_SR);

-	if (unlikely(!__ipipe_mach_timerstolen)) {
-		__ipipe_tsc_update();
-		next_match = (next_match + __ipipe_mach_ticks_per_jiffy)
-			& AT91_TC_REG_MASK;
-		write_RC(next_match);
-	}
+	if (unlikely(!__ipipe_mach_timerstolen))
+		__ipipe_mach_set_dec(max_delta_ticks);
 }

 static void
@@ -147,7 +145,7 @@ at91_tc_set_mode(enum clock_event_mode mode, struct
clock_event_device *dev)
 	/* Disable all interrupts. */
 	at91_tc_write(AT91_TC_IDR, ~0ul);

-	if (mode == CLOCK_EVT_MODE_PERIODIC) {
+	if (mode == CLOCK_EVT_MODE_ONESHOT) {
 		unsigned long v;

 #ifndef CONFIG_ARCH_AT91SAM9263
@@ -169,9 +167,7 @@ at91_tc_set_mode(enum clock_event_mode mode, struct
clock_event_device *dev)
 		/* Use the clock selected by at91_timer_init as input clock. */
 		at91_tc_write(AT91_TC_CMR, tc_timer_clock);

-		/* Load the TC register C. */
-		next_match = __ipipe_mach_ticks_per_jiffy;
-		write_RC(next_match);
+		__ipipe_mach_set_dec(max_delta_ticks);

 		/* Enable CPCS interrupt. */
 		at91_tc_write(AT91_TC_IER, AT91_TC_CPCS);
@@ -181,6 +177,14 @@ at91_tc_set_mode(enum clock_event_mode mode, struct
clock_event_device *dev)
 	}
 }

+static int
+at91_tc_set_next_event(unsigned long delta, struct clock_event_device *dev)
+{
+	tick_pending = 1;
+	__ipipe_mach_set_dec(delta);
+	return 0;
+}
+
 /*
  * Reprogram the timer
  */
@@ -208,10 +212,11 @@ int __ipipe_check_tickdev(const char *devname)

 static struct clock_event_device clkevt = {
 	.name		= "at91_tc" __stringify(CONFIG_IPIPE_AT91_TC),
-	.features	= CLOCK_EVT_FEAT_PERIODIC,
+	.features	= CLOCK_EVT_FEAT_ONESHOT,
 	.shift		= 20,
 	.rating		= 250,
 	.set_mode	= at91_tc_set_mode,
+	.set_next_event = at91_tc_set_next_event,
 };

 static struct __ipipe_tscinfo tsc_info = {
@@ -230,7 +235,7 @@ static struct __ipipe_tscinfo tsc_info = {

 void __ipipe_mach_release_timer(void)
 {
-	__ipipe_mach_set_dec(__ipipe_mach_ticks_per_jiffy);
+	clkevt.set_next_event(__ipipe_mach_ticks_per_jiffy, &clkevt);
 }
 EXPORT_SYMBOL(__ipipe_mach_release_timer);

@@ -293,15 +298,16 @@ void __init at91_timer_init(void)
 	clkevt.max_delta_ns = wrap_ns;
 	clkevt.min_delta_ns = 2000;
 	clkevt.cpumask = cpumask_of(0);
-	clockevents_register_device(&clkevt);
-
-	tsc_info.freq = divided_freq;
-	__ipipe_tsc_register(&tsc_info);

 	__ipipe_mach_ticks_per_jiffy = (divided_freq + HZ/2) / HZ;
 	max_delta_ticks = (wrap_ns * clkevt.mult) >> clkevt.shift;
 	min_delta_ticks = ((unsigned long long) clkevt.min_delta_ns
 			   * clkevt.mult) >> clkevt.shift;
+
+	clockevents_register_device(&clkevt);
+
+	tsc_info.freq = divided_freq;
+	__ipipe_tsc_register(&tsc_info);
 }

 #ifdef CONFIG_ARCH_AT91RM9200


-- 
                                                                Gilles.

Re: [Xenomai-help] High resolution timers disabled on AT91SAM9G20 board after patching

[at91_enthus]

[-- Attachment #1.1: Type: text/plain, Size: 6037 bytes --]

Yes, it solved the issue.

There is  one thing that bothers me, though. When I run  "xeno-test", the
average and minimal  latencies are constant all the time.

The unpatched version of the xeno kernel seems more consistent when it comes
to minimum, maximum and average latencies.

I attached a couple of snippets of  xeno-test outputs .

Thanks,

R.

On Sun, Nov 7, 2010 at 4:45 AM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> Gilles Chanteperdrix wrote:
> > at91_enthus wrote:
> >> Hi!
> >>
> >> I installed the latest xenomai patch on a AT91SAM9G20 board and
> >> everything looked good at a first glance: no compilation problems, low
> >> latencies.
> >>
> >> However, when I typed cat /proc/timer_list , the resolutions in  cpu0
> >> and cpu1 items showed 100000 (ns).
> >> (I compiled the Xenomai patched kernel with High Resolution Timers
> enabled.)
> >>
> >> I don't have this problem when I boot a real time kernel (RT_PREEMPT).
> >
> > You mean another real-time kernel? If RT_PREEMPT uses the sys timer
> > running at 32kHz, and it tells you that it has a 1ns resolution, then it
> > is lying, because 32kHz, means a 30us resolution.
> >
> > Xenomai uses one TC as a timer at whatever frequency your chip proposes
> > over 1 MHz, this means a resolution below 1us, the downside is that this
> > also means a very short wrap time. And since the TC is also used as a
> > clock, this means that we must enter the timer interrupt handler before
> > the counter wraps. And this is something that Linux without Xenomai
> > running can not guarantee.
>
> On the other hand, we can keep the timer ticking behind Linux' back.
> Does the following patch fix the issue for you?
>
> diff --git a/arch/arm/mach-at91/at91_ipipe_time.c
> b/arch/arm/mach-at91/at91_ipipe_time.c
> index b0327eb..6c6f0d7 100644
> --- a/arch/arm/mach-at91/at91_ipipe_time.c
> +++ b/arch/arm/mach-at91/at91_ipipe_time.c
> @@ -76,9 +76,7 @@
>  #define TCNXCNS(timer,v) ((v) << ((timer)<<1))
>  #define AT91_TC_REG_MASK (0xffff)
>
> -static unsigned long next_match;
> -
> -static unsigned max_delta_ticks, min_delta_ticks;
> +static unsigned max_delta_ticks, min_delta_ticks, tick_pending;
>  static struct clock_event_device clkevt;
>  static int tc_timer_clock;
>
> @@ -116,7 +114,11 @@ EXPORT_SYMBOL(__ipipe_mach_ticks_per_jiffy);
>  */
>  static irqreturn_t at91_timer_interrupt(int irq, void *dev_id)
>  {
> -       clkevt.event_handler(&clkevt);
> +       if (__ipipe_mach_timerstolen || tick_pending) {
> +               tick_pending = 0;
> +               clkevt.event_handler(&clkevt);
> +       }
> +
>        return IRQ_HANDLED;
>  }
>
> @@ -130,12 +132,8 @@ void __ipipe_mach_acktimer(void)
>  {
>        at91_tc_read(AT91_TC_SR);
>
> -       if (unlikely(!__ipipe_mach_timerstolen)) {
> -               __ipipe_tsc_update();
> -               next_match = (next_match + __ipipe_mach_ticks_per_jiffy)
> -                       & AT91_TC_REG_MASK;
> -               write_RC(next_match);
> -       }
> +       if (unlikely(!__ipipe_mach_timerstolen))
> +               __ipipe_mach_set_dec(max_delta_ticks);
>  }
>
>  static void
> @@ -147,7 +145,7 @@ at91_tc_set_mode(enum clock_event_mode mode, struct
> clock_event_device *dev)
>        /* Disable all interrupts. */
>        at91_tc_write(AT91_TC_IDR, ~0ul);
>
> -       if (mode == CLOCK_EVT_MODE_PERIODIC) {
> +       if (mode == CLOCK_EVT_MODE_ONESHOT) {
>                unsigned long v;
>
>  #ifndef CONFIG_ARCH_AT91SAM9263
> @@ -169,9 +167,7 @@ at91_tc_set_mode(enum clock_event_mode mode, struct
> clock_event_device *dev)
>                /* Use the clock selected by at91_timer_init as input clock.
> */
>                at91_tc_write(AT91_TC_CMR, tc_timer_clock);
>
> -               /* Load the TC register C. */
> -               next_match = __ipipe_mach_ticks_per_jiffy;
> -               write_RC(next_match);
> +               __ipipe_mach_set_dec(max_delta_ticks);
>
>                /* Enable CPCS interrupt. */
>                at91_tc_write(AT91_TC_IER, AT91_TC_CPCS);
> @@ -181,6 +177,14 @@ at91_tc_set_mode(enum clock_event_mode mode, struct
> clock_event_device *dev)
>        }
>  }
>
> +static int
> +at91_tc_set_next_event(unsigned long delta, struct clock_event_device
> *dev)
> +{
> +       tick_pending = 1;
> +       __ipipe_mach_set_dec(delta);
> +       return 0;
> +}
> +
>  /*
>  * Reprogram the timer
>  */
> @@ -208,10 +212,11 @@ int __ipipe_check_tickdev(const char *devname)
>
>  static struct clock_event_device clkevt = {
>        .name           = "at91_tc" __stringify(CONFIG_IPIPE_AT91_TC),
> -       .features       = CLOCK_EVT_FEAT_PERIODIC,
> +       .features       = CLOCK_EVT_FEAT_ONESHOT,
>        .shift          = 20,
>        .rating         = 250,
>        .set_mode       = at91_tc_set_mode,
> +       .set_next_event = at91_tc_set_next_event,
>  };
>
>  static struct __ipipe_tscinfo tsc_info = {
> @@ -230,7 +235,7 @@ static struct __ipipe_tscinfo tsc_info = {
>
>  void __ipipe_mach_release_timer(void)
>  {
> -       __ipipe_mach_set_dec(__ipipe_mach_ticks_per_jiffy);
> +       clkevt.set_next_event(__ipipe_mach_ticks_per_jiffy, &clkevt);
>  }
>  EXPORT_SYMBOL(__ipipe_mach_release_timer);
>
> @@ -293,15 +298,16 @@ void __init at91_timer_init(void)
>        clkevt.max_delta_ns = wrap_ns;
>        clkevt.min_delta_ns = 2000;
>        clkevt.cpumask = cpumask_of(0);
> -       clockevents_register_device(&clkevt);
> -
> -       tsc_info.freq = divided_freq;
> -       __ipipe_tsc_register(&tsc_info);
>
>        __ipipe_mach_ticks_per_jiffy = (divided_freq + HZ/2) / HZ;
>        max_delta_ticks = (wrap_ns * clkevt.mult) >> clkevt.shift;
>        min_delta_ticks = ((unsigned long long) clkevt.min_delta_ns
>                           * clkevt.mult) >> clkevt.shift;
> +
> +       clockevents_register_device(&clkevt);
> +
> +       tsc_info.freq = divided_freq;
> +       __ipipe_tsc_register(&tsc_info);
>  }
>
>  #ifdef CONFIG_ARCH_AT91RM9200
>
>
> --
>                                             Gilles.
>

[-- Attachment #1.2: Type: text/html, Size: 7068 bytes --]

[-- Attachment #2: benchmark_no_patch --]
[-- Type: application/octet-stream, Size: 1845 bytes --]

warming up...
RTT|  00:00:01  (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|     13.565|     13.565|     19.379|       0|     0|     13.565|     19.379
RTD|     13.565|     15.503|     74.612|       0|     0|     13.565|     74.612
RTD|     13.565|     45.542|     72.674|       0|     0|     13.565|     74.612
RTD|     14.534|     14.534|     38.759|       0|     0|     13.565|     74.612
RTD|     56.201|     57.170|     80.426|       0|     0|     13.565|     80.426
RTD|     14.534|     14.534|     34.883|       0|     0|     13.565|     80.426
RTD|     56.201|     56.201|     71.705|       0|     0|     13.565|     80.426
RTD|     14.534|     45.542|     72.674|       0|     0|     13.565|     80.426
RTD|     14.534|     14.534|     31.007|       0|     0|     13.565|     80.426
RTD|     18.410|     56.201|     81.395|       0|     0|     13.565|     81.395
RTD|     14.534|     14.534|     30.038|       0|     0|     13.565|     81.395
RTD|     13.565|     14.534|     33.914|       0|     0|     13.565|     81.395
RTD|     55.232|     56.201|     76.550|       0|     0|     13.565|     81.395
RTD|     14.534|     14.534|     35.852|       0|     0|     13.565|     81.395
RTD|     56.201|     57.170|     80.426|       0|     0|     13.565|     81.395
RTD|     13.565|     14.534|     50.387|       0|     0|     13.565|     81.395
RTD|     56.201|     56.201|     72.674|       0|     0|     13.565|     81.395
RTD|     14.534|     45.542|     73.643|       0|     0|     13.565|     81.395
RTD|     14.534|     14.534|     31.007|       0|     0|     13.565|     81.395
RTD|     18.410|     56.201|     80.426|       0|     0|     13.565|     81.395
RTD|     14.534|     14.534|     32.945|       0|     0|     13.565|     81.395

[-- Attachment #3: benchmark_patched --]
[-- Type: application/octet-stream, Size: 1845 bytes --]

warming up...
RTT|  00:00:01  (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|     47.480|     47.480|     50.387|       0|     0|     47.480|     50.387
RTD|     47.480|     47.480|     67.829|       0|     0|     47.480|     67.829
RTD|     47.480|     47.480|     59.108|       0|     0|     47.480|     67.829
RTD|     47.480|     47.480|     65.891|       0|     0|     47.480|     67.829
RTD|     47.480|     47.480|     67.829|       0|     0|     47.480|     67.829
RTD|     47.480|     47.480|     61.046|       0|     0|     47.480|     67.829
RTD|     47.480|     47.480|     59.108|       0|     0|     47.480|     67.829
RTD|     47.480|     47.480|     61.046|       0|     0|     47.480|     67.829
RTD|     47.480|     47.480|     59.108|       0|     0|     47.480|     67.829
RTD|     47.480|     47.480|     59.108|       0|     0|     47.480|     67.829
RTD|     47.480|     47.480|     77.519|       0|     0|     47.480|     77.519
RTD|     47.480|     47.480|     58.139|       0|     0|     47.480|     77.519
RTD|     47.480|     47.480|     58.139|       0|     0|     47.480|     77.519
RTD|     47.480|     47.480|     59.108|       0|     0|     47.480|     77.519
RTD|     47.480|     47.480|     58.139|       0|     0|     47.480|     77.519
RTD|     47.480|     47.480|     61.046|       0|     0|     47.480|     77.519
RTD|     47.480|     47.480|     77.519|       0|     0|     47.480|     77.519
RTD|     47.480|     47.480|     58.139|       0|     0|     47.480|     77.519
RTD|     47.480|     47.480|     59.108|       0|     0|     47.480|     77.519
RTD|     47.480|     47.480|     60.077|       0|     0|     47.480|     77.519
RTD|     47.480|     47.480|     60.077|       0|     0|     47.480|     77.519

Re: [Xenomai-help] High resolution timers disabled on AT91SAM9G20 board after patching

[Gilles Chanteperdrix]

at91_enthus wrote:
> Yes, it solved the issue.
> 
> There is  one thing that bothers me, though. When I run  "xeno-test", the
> average and minimal  latencies are constant all the time.
> 
> The unpatched version of the xeno kernel seems more consistent when it comes
> to minimum, maximum and average latencies.
> 
> I attached a couple of snippets of  xeno-test outputs .

Do not trust xeno-test too much. Are you sure the only difference
between the two runs is the patch, for instance, have you not played
with the CONFIG_ARM_FCSE option? Also, good benchmarks are done with
running a separate load, and not with xeno-test, in fact.

Also, using the high-res timers configuration has a high overhead on
such low-end configurations as AT91s, so has CONFIG_PREEMPT. So, if you
are looking for a configuration with the lowest overhead possible, I
would recommend disabling CONFIG_HIGH_RES_TIMERS and using
CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY, and relying on Xenomai
for the low latency and high resolution timer features. (You can measure
the overhead of kernel options with the hackbench test for instance).

On the AT91 I have (AT91SAM9263), the minimum and average latencies
oscillate much less than for your unpatched kernel, either with or
without the patch so I wonder if you would not have another issue. Do
you have FCSE enabled?

To give you an idea of the figures here, with FCSE enabled, the minimal
latency is around 15us and the average latency around 50us. And they
vary in a 5us range, they do not make big jumps.


-- 
                                                                Gilles.

Re: [Xenomai-help] High resolution timers disabled on AT91SAM9G20 board after patching

[at91_enthus]

[-- Attachment #1: Type: text/plain, Size: 1990 bytes --]

Indeed, there's a huge difference regarding minimum and average latencies
now that FCSE is enabled and HRT and CONFIG_PREEMPT are disabled. I get
around 13.5 microseconds average latencies.

Thanks a lot.

On Sun, Nov 7, 2010 at 11:15 AM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> at91_enthus wrote:
> > Yes, it solved the issue.
> >
> > There is  one thing that bothers me, though. When I run  "xeno-test", the
> > average and minimal  latencies are constant all the time.
> >
> > The unpatched version of the xeno kernel seems more consistent when it
> comes
> > to minimum, maximum and average latencies.
> >
> > I attached a couple of snippets of  xeno-test outputs .
>
> Do not trust xeno-test too much. Are you sure the only difference
> between the two runs is the patch, for instance, have you not played
> with the CONFIG_ARM_FCSE option? Also, good benchmarks are done with
> running a separate load, and not with xeno-test, in fact.
>
> Also, using the high-res timers configuration has a high overhead on
> such low-end configurations as AT91s, so has CONFIG_PREEMPT. So, if you
> are looking for a configuration with the lowest overhead possible, I
> would recommend disabling CONFIG_HIGH_RES_TIMERS and using
> CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY, and relying on Xenomai
> for the low latency and high resolution timer features. (You can measure
> the overhead of kernel options with the hackbench test for instance).
>
> On the AT91 I have (AT91SAM9263), the minimum and average latencies
> oscillate much less than for your unpatched kernel, either with or
> without the patch so I wonder if you would not have another issue. Do
> you have FCSE enabled?
>
> To give you an idea of the figures here, with FCSE enabled, the minimal
> latency is around 15us and the average latency around 50us. And they
> vary in a 5us range, they do not make big jumps.
>
>
> --
>                                                                 Gilles.
>

[-- Attachment #2: Type: text/html, Size: 2477 bytes --]

Re: [Xenomai-help] High resolution timers disabled on AT91SAM9G20 board after patching

[Gilles Chanteperdrix]

at91_enthus wrote:
> Indeed, there's a huge difference regarding minimum and average latencies
> now that FCSE is enabled and HRT and CONFIG_PREEMPT are disabled. I get
> around 13.5 microseconds average latencies.

Wow. Under load?

-- 
                                                                Gilles.

Re: [Xenomai-help] High resolution timers disabled on AT91SAM9G20 board after patching

[at91_enthus]

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

Xeno-test is the only benchmark I have for the time being (I just started
with xenomai).
So if you consider that  "dd if=.. of=.."  is a reliable load, then yes.

Here's a snippet of xeno-test's output:

warming up...
RTT|  00:00:01  (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat
worst
RTD|     12.596|     13.565|     24.224|       0|     0|     12.596|
24.224
RTD|     12.596|     13.565|     32.945|       0|     0|     12.596|
32.945
RTD|     13.565|     13.565|     37.790|       0|     0|     12.596|
37.790

R.

On Sun, Nov 7, 2010 at 2:24 PM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> at91_enthus wrote:
> > Indeed, there's a huge difference regarding minimum and average latencies
> > now that FCSE is enabled and HRT and CONFIG_PREEMPT are disabled. I get
> > around 13.5 microseconds average latencies.
>
> Wow. Under load?
>
> --
>                                                                 Gilles.
>

[-- Attachment #2: Type: text/html, Size: 1547 bytes --]