[Xenomai-help] irqloop hangs on Beagleboard ARM with 2.5.5.2/2.6.33

[Xenomai-help] irqloop hangs on Beagleboard ARM with 2.5.5.2/2.6.33

[Eric Eric]

Hi, I'm attempting to run irqloop/irqbench and irqloop just appears to
hang indefinitely.  Behavior is the same with -t0 and -t1.  I am able
to successfully run other tests such as latency and switchtest.  Below
is the output of strace ./irqloop -t1. xeno_irqbench is loaded, I have
a null modem cable connected to an x86 running irqbench and have
disabled the serial log output and serial tty on the beagle.

futex(0x40040d60, FUTEX_WAKE_PRIVATE, 2147483647) = 0
open("/dev/rtheap", O_RDWR)             = 3
ioctl(3, 0, 0xc08aa1d8)                 = 0
mmap2(NULL, 12288, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x4017a000
close(3)                                = 0
futex(0x40040d64, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x40040c8c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x40040d50, FUTEX_WAKE_PRIVATE, 2147483647) = 0
rt_sigaction(SIGXCPU, {0x400362f0, [], SA_SIGINFO|0x4000000}, NULL, 8) = 0
mlockall(MCL_CURRENT|MCL_FUTURE)        = 0
sched_getparam(2947, { 0 })             = 0
sched_getscheduler(2947)                = 0 (SCHED_OTHER)
brk(0)                                  = 0x12000
brk(0x33000)                            = 0x33000
rt_sigaction(SIGWINCH, {0x40036e58, [],
SA_RESTART|SA_SIGINFO|0x4000000}, {SIG_DFL, [], 0}, 8) = 0
--- SIGWINCH (Window changed) @ 0 (0) ---
sched_setscheduler(2947, SCHED_OTHER, { 0 }) = 0
rt_sigreturn(0x1)                       = 0
futex(0x40040c90, FUTEX_WAKE_PRIVATE, 2147483647) = 0
munlockall()                            = 0
sched_get_priority_max(SCHED_FIFO)      = 99
rt_sigaction(SIGINT, {0x8adc, [INT], SA_RESTART|0x4000000}, {SIG_DFL,
[], 0}, 8) = 0
rt_sigaction(SIGTERM, {0x8adc, [TERM], SA_RESTART|0x4000000},
{SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGHUP, {0x8adc, [HUP], SA_RESTART|0x4000000}, {SIG_DFL,
[], 0}, 8) = 0
mlockall(MCL_CURRENT|MCL_FUTURE)        = 0

Thanks for any assistance.

- Eric

Re: [Xenomai-help] irqloop hangs on Beagleboard ARM with 2.5.5.2/2.6.33

[Gilles Chanteperdrix]

Eric Eric wrote:
> Hi, I'm attempting to run irqloop/irqbench and irqloop just appears to
> hang indefinitely.  Behavior is the same with -t0 and -t1.  I am able
> to successfully run other tests such as latency and switchtest.  Below
> is the output of strace ./irqloop -t1. xeno_irqbench is loaded, I have
> a null modem cable connected to an x86 running irqbench and have
> disabled the serial log output and serial tty on the beagle.

I am not sure, but I think irqloop currently only works on x86. You
should try gpioirqbench instead.

http://www.denx.de/wiki/DULG/AN2008_03_Xenomai_gpioirqbench

-- 
                                                                Gilles.

Re: [Xenomai-help] irqloop hangs on Beagleboard ARM with 2.5.5.2/2.6.33

[Wolfgang Grandegger]

On 03/07/2011 09:29 AM, Gilles Chanteperdrix wrote:
> Eric Eric wrote:
>> Hi, I'm attempting to run irqloop/irqbench and irqloop just appears to
>> hang indefinitely.  Behavior is the same with -t0 and -t1.  I am able
>> to successfully run other tests such as latency and switchtest.  Below
>> is the output of strace ./irqloop -t1. xeno_irqbench is loaded, I have
>> a null modem cable connected to an x86 running irqbench and have
>> disabled the serial log output and serial tty on the beagle.
> 
> I am not sure, but I think irqloop currently only works on x86. You
> should try gpioirqbench instead.
> 
> http://www.denx.de/wiki/DULG/AN2008_03_Xenomai_gpioirqbench


Yes, irqbench requires a 16650-compatible serial or parallel interface
accessible via ioports, which is usually not available on embedded
systems. In contrast, gpioirqbench uses GPIO pins but getting it working
on the Beagle board is also not straight-forward. At least it does not
work out-of-the-box.

Wolfgang.

Re: [Xenomai-help] irqloop hangs on Beagleboard ARM with 2.5.5.2/2.6.33

[Eric Eric]

OK, it looks like I would basically have to replace gpioirq-hw.h
bare-bones GPIO driver for the beagle to get this to work.  Other than
that, am I correct that the hardware configuration would be two boards
connected to each other using two GPIO pins for trigger and response?

On a related note, I'm trying to figure out what exactly the latency
program measures.  From the code, it looks like it's measuring timer
jitter and latency (ie it registers a timer for 1mS from now, the when
the timer fires the timer procedure records how far current time is
from the requested fire time).  Is this correct?

Lastly, I'm trying to get some idea of context switch latency.  I see
a man page for "switchbench" but can't seem to find code or binaries
for switchbench.  Any ideas?  I've been using switchtest instead.  It
seems like switchtest fires up a bunch of threads and measure how man
context switches it can do among them.  On my board, I see about
10,000/sec.  Is this equivalent to a 100uS context switch time?  Maybe
it's a stupid question, but something tells me these two things may
not be equivalent.

Thank you again for the prompt and helpful response.

- Eric

On Mon, Mar 7, 2011 at 6:50 AM, Wolfgang Grandegger <wg@domain.hid> wrote:
> On 03/07/2011 09:29 AM, Gilles Chanteperdrix wrote:
>> Eric Eric wrote:
>>> Hi, I'm attempting to run irqloop/irqbench and irqloop just appears to
>>> hang indefinitely.  Behavior is the same with -t0 and -t1.  I am able
>>> to successfully run other tests such as latency and switchtest.  Below
>>> is the output of strace ./irqloop -t1. xeno_irqbench is loaded, I have
>>> a null modem cable connected to an x86 running irqbench and have
>>> disabled the serial log output and serial tty on the beagle.
>>
>> I am not sure, but I think irqloop currently only works on x86. You
>> should try gpioirqbench instead.
>>
>> http://www.denx.de/wiki/DULG/AN2008_03_Xenomai_gpioirqbench
>
>
> Yes, irqbench requires a 16650-compatible serial or parallel interface
> accessible via ioports, which is usually not available on embedded
> systems. In contrast, gpioirqbench uses GPIO pins but getting it working
> on the Beagle board is also not straight-forward. At least it does not
> work out-of-the-box.
>
> Wolfgang.
>
>

Re: [Xenomai-help] irqloop hangs on Beagleboard ARM with 2.5.5.2/2.6.33

[Gilles Chanteperdrix]

Eric Eric wrote:
> OK, it looks like I would basically have to replace gpioirq-hw.h
> bare-bones GPIO driver for the beagle to get this to work.  Other than
> that, am I correct that the hardware configuration would be two boards
> connected to each other using two GPIO pins for trigger and response?

Well, the gpiolib functions are safe to be used from real-time domain.

> 
> On a related note, I'm trying to figure out what exactly the latency
> program measures.  From the code, it looks like it's measuring timer
> jitter and latency (ie it registers a timer for 1mS from now, the when
> the timer fires the timer procedure records how far current time is
> from the requested fire time).  Is this correct?

It is measuring the user-space thread, kernel-space thread, or
kernel-space timer interrupt latency depending on whether you use -t0,
-t1, or -t2. If prior to running the latency test you do:
echo 0 > /proc/xenomai/latency
the measured latency is the same as what the latency will be for any
interrupt, not just the timer, with the exception of the GPIO demuxed
interrupts, which should have slightly larger latencies, due to the fact
that they need to be decoded.

On omap3530, the user-space worst case user-space scheduling latency
should be around 55us at 1kHz, and 35us at 10kHz, if you use the
user-space tsc emulation. I still have not tested the 3730.

> 
> Lastly, I'm trying to get some idea of context switch latency.  I see
> a man page for "switchbench" but can't seem to find code or binaries
> for switchbench.  Any ideas?  I've been using switchtest instead.  It
> seems like switchtest fires up a bunch of threads and measure how man
> context switches it can do among them.  On my board, I see about
> 10,000/sec.  Is this equivalent to a 100uS context switch time?  Maybe
> it's a stupid question, but something tells me these two things may
> not be equivalent.

No, switchtest sleeps from time to time, so, the count of context
switches does not mean anything. The aim of switchtest is rather to
stress the machine with many context switches, including testing FPU
switches, in order to find errors in these routines. Note that the worst
case user-space thread scheduling latency path includes a context
switch, so, the context switch time can not be larger than the result
given by the "latency" test.

switchbench was been renamed wakeup-time so time ago.

-- 
					    Gilles.

Re: [Xenomai-help] irqloop hangs on Beagleboard ARM with 2.5.5.2/2.6.33

[Eric Eric]

On Mon, Mar 7, 2011 at 2:07 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> Eric Eric wrote:
>> OK, it looks like I would basically have to replace gpioirq-hw.h
>> bare-bones GPIO driver for the beagle to get this to work.  Other than
>> that, am I correct that the hardware configuration would be two boards
>> connected to each other using two GPIO pins for trigger and response?
>
> Well, the gpiolib functions are safe to be used from real-time domain.

Hmm, it looked like gpioirqbench went through some pain to -not- use
gpiolib and to manually configure and operate the hardware, so I
assumed this was not safe.  It's certainly a more pleasant task using
gpiolib.  It does beg the question why gpioirqbench isn't doing this.

>
>>
>> On a related note, I'm trying to figure out what exactly the latency
>> program measures.  From the code, it looks like it's measuring timer
>> jitter and latency (ie it registers a timer for 1mS from now, the when
>> the timer fires the timer procedure records how far current time is
>> from the requested fire time).  Is this correct?
>
> It is measuring the user-space thread, kernel-space thread, or
> kernel-space timer interrupt latency depending on whether you use -t0,
> -t1, or -t2. If prior to running the latency test you do:
> echo 0 > /proc/xenomai/latency
> the measured latency is the same as what the latency will be for any
> interrupt, not just the timer, with the exception of the GPIO demuxed
> interrupts, which should have slightly larger latencies, due to the fact
> that they need to be decoded.

Right, but is it possible to discern actual latency from timer
hardware jitter?  Or is this particular timer of sufficient precision
that the jitter is orders of magnitude lower than the latency?

>
> On omap3530, the user-space worst case user-space scheduling latency
> should be around 55us at 1kHz, and 35us at 10kHz, if you use the
> user-space tsc emulation. I still have not tested the 3730.

This seems consistent with my results, assuming I'm using 1kHZ.  Are
you referring to CONFIG_XENO_OPT_TIMING_VIRTICK here?

>
>>
>> Lastly, I'm trying to get some idea of context switch latency.  I see
>> a man page for "switchbench" but can't seem to find code or binaries
>> for switchbench.  Any ideas?  I've been using switchtest instead.  It
>> seems like switchtest fires up a bunch of threads and measure how man
>> context switches it can do among them.  On my board, I see about
>> 10,000/sec.  Is this equivalent to a 100uS context switch time?  Maybe
>> it's a stupid question, but something tells me these two things may
>> not be equivalent.
>
> No, switchtest sleeps from time to time, so, the count of context
> switches does not mean anything. The aim of switchtest is rather to
> stress the machine with many context switches, including testing FPU
> switches, in order to find errors in these routines. Note that the worst
> case user-space thread scheduling latency path includes a context
> switch, so, the context switch time can not be larger than the result
> given by the "latency" test.
>
> switchbench was been renamed wakeup-time so time ago.

Got it, it may be worth filing a bug to rename the man page.  My
results were 24/26/46uS, which seems consistent with my other results
and with your advice.

Thanks again.

- Eric

>
> --
>                                            Gilles.
>

Re: [Xenomai-help] irqloop hangs on Beagleboard ARM with 2.5.5.2/2.6.33

[Gilles Chanteperdrix]

Eric Eric wrote:
> On Mon, Mar 7, 2011 at 2:07 PM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> Eric Eric wrote:
>>> OK, it looks like I would basically have to replace gpioirq-hw.h
>>> bare-bones GPIO driver for the beagle to get this to work.  Other than
>>> that, am I correct that the hardware configuration would be two boards
>>> connected to each other using two GPIO pins for trigger and response?
>> Well, the gpiolib functions are safe to be used from real-time domain.
> 
> Hmm, it looked like gpioirqbench went through some pain to -not- use
> gpiolib and to manually configure and operate the hardware, so I
> assumed this was not safe.  It's certainly a more pleasant task using
> gpiolib.  It does beg the question why gpioirqbench isn't doing this.

The reason is historical.

> 
>>> On a related note, I'm trying to figure out what exactly the latency
>>> program measures.  From the code, it looks like it's measuring timer
>>> jitter and latency (ie it registers a timer for 1mS from now, the when
>>> the timer fires the timer procedure records how far current time is
>>> from the requested fire time).  Is this correct?
>> It is measuring the user-space thread, kernel-space thread, or
>> kernel-space timer interrupt latency depending on whether you use -t0,
>> -t1, or -t2. If prior to running the latency test you do:
>> echo 0 > /proc/xenomai/latency
>> the measured latency is the same as what the latency will be for any
>> interrupt, not just the timer, with the exception of the GPIO demuxed
>> interrupts, which should have slightly larger latencies, due to the fact
>> that they need to be decoded.
> 
> Right, but is it possible to discern actual latency from timer
> hardware jitter?  Or is this particular timer of sufficient precision
> that the jitter is orders of magnitude lower than the latency?

I would expect the timer to have a very small jitter. Since it is
multi-MHz, it would be a bit awkward if it had a latency greater than 1us.

Anyway, it is true that we have a small uncertainty here, due to the
fact that we are treating all timers as if they were decrementers, so,
we are computing a delay, then programming it a bit later, trying to
account for the programming latency of the timer, whereas the omap3
timer, like many timers, at least on ARM, is a free-running counter with
a match registers, so that we could get really precise programming.

But this should account for 1 or 2us uncertainty, still far from 55us.
One day, we will fix this...

> 
>> On omap3530, the user-space worst case user-space scheduling latency
>> should be around 55us at 1kHz, and 35us at 10kHz, if you use the
>> user-space tsc emulation. I still have not tested the 3730.
> 
> This seems consistent with my results, assuming I'm using 1kHZ.  Are
> you referring to CONFIG_XENO_OPT_TIMING_VIRTICK here?

I am referring to --enable-arm-mach=omap3 passed to Xenomai user-space
compilation configure script (which automatically enables --enable-arm-tsc).

>> No, switchtest sleeps from time to time, so, the count of context
>> switches does not mean anything. The aim of switchtest is rather to
>> stress the machine with many context switches, including testing FPU
>> switches, in order to find errors in these routines. Note that the worst
>> case user-space thread scheduling latency path includes a context
>> switch, so, the context switch time can not be larger than the result
>> given by the "latency" test.
>>
>> switchbench was been renamed wakeup-time so time ago.
> 
> Got it, it may be worth filing a bug to rename the man page.  My
> results were 24/26/46uS, which seems consistent with my other results
> and with your advice.

We forgot the man-page, sorry.

-- 
                                                                Gilles.

Re: [Xenomai-help] irqloop hangs on Beagleboard ARM with 2.5.5.2/2.6.33

[Wolfgang Grandegger]

On 03/07/2011 10:27 PM, Gilles Chanteperdrix wrote:
> Eric Eric wrote:
>> On Mon, Mar 7, 2011 at 2:07 PM, Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org> wrote:
>>> Eric Eric wrote:
>>>> OK, it looks like I would basically have to replace gpioirq-hw.h
>>>> bare-bones GPIO driver for the beagle to get this to work.  Other than
>>>> that, am I correct that the hardware configuration would be two boards
>>>> connected to each other using two GPIO pins for trigger and response?
>>> Well, the gpiolib functions are safe to be used from real-time domain.
>>
>> Hmm, it looked like gpioirqbench went through some pain to -not- use
>> gpiolib and to manually configure and operate the hardware, so I
>> assumed this was not safe.  It's certainly a more pleasant task using
>> gpiolib.  It does beg the question why gpioirqbench isn't doing this.
> 
> The reason is historical.

Right, at that time only a few archs/systems supported the gpolib,
especially with interrupts. But I already have an implementation for the
Qong i.MX31 board using the generic gpiolib. I will dig for it later
this week. "gpioirqbench" measures how fast iPipe or Xenomai software
can respond to an external event (interrupt) in a user-space or
kernel-space task or the Xenomai or iPipe interrupt handler. Anyway,
"gpioirqbench" also needs a host to trigger and measure the latencies in
*hardware*. This is the tricky part. I used a mpc8xx based system.

Wolfgang.

Re: [Xenomai-help] irqloop hangs on Beagleboard ARM with 2.5.5.2/2.6.33

[Eric Eric]

Hi Wolfgang, were you able to find the gpiolib irqloop implementation?
I'm still interested in running this experiment on the Beagleboard.

Thanks,

- Eric

On Mon, Mar 7, 2011 at 5:16 PM, Wolfgang Grandegger <wg@domain.hid> wrote:
> On 03/07/2011 10:27 PM, Gilles Chanteperdrix wrote:
>> Eric Eric wrote:
>>> On Mon, Mar 7, 2011 at 2:07 PM, Gilles Chanteperdrix
>>> <gilles.chanteperdrix@xenomai.org> wrote:
>>>> Eric Eric wrote:
>>>>> OK, it looks like I would basically have to replace gpioirq-hw.h
>>>>> bare-bones GPIO driver for the beagle to get this to work.  Other than
>>>>> that, am I correct that the hardware configuration would be two boards
>>>>> connected to each other using two GPIO pins for trigger and response?
>>>> Well, the gpiolib functions are safe to be used from real-time domain.
>>>
>>> Hmm, it looked like gpioirqbench went through some pain to -not- use
>>> gpiolib and to manually configure and operate the hardware, so I
>>> assumed this was not safe.  It's certainly a more pleasant task using
>>> gpiolib.  It does beg the question why gpioirqbench isn't doing this.
>>
>> The reason is historical.
>
> Right, at that time only a few archs/systems supported the gpolib,
> especially with interrupts. But I already have an implementation for the
> Qong i.MX31 board using the generic gpiolib. I will dig for it later
> this week. "gpioirqbench" measures how fast iPipe or Xenomai software
> can respond to an external event (interrupt) in a user-space or
> kernel-space task or the Xenomai or iPipe interrupt handler. Anyway,
> "gpioirqbench" also needs a host to trigger and measure the latencies in
> *hardware*. This is the tricky part. I used a mpc8xx based system.
>
> Wolfgang.
>