[Xenomai-help] gpioirqbench: measuring external interrupt latencies

[Xenomai-help] gpioirqbench: measuring external interrupt latencies

[Wolfgang Grandegger]

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

Hello,

I'm proud to announce "gpioirqbench", a benchmark tool to measure
external interrupt latencies. It is derived from Jan's irqbench [1] for
the PC. Instead of using the serial or parallel port, it uses GPIO pins
on embedded systems. It measures the time between the generation of an
interrupt triggered by a GPIO pin and the reply by either the interrupt
service routine, a kernel-space task or a user-space task. As reply,
another GPIO pin will be toggled. The setup consists of two systems, the
log host and the test target. The log host triggers the interrupt on the
test target and measures the latency. This benchmark is primarily for
Xenomai/RTDM, but it can also be used for plain Linux or even Linux-rt
(with the real-time preemption patch).

I have done a series of latency measurements with the embedded PowerPC
evaluation board Icecube-Freescale-MPC5200 and Sequoia-AMCC-440EPx. The
results are listed below:


1) Board: Motorola MPC5200 (IceCube)
   CPU:   MPC5200 v1.0, Core v1.1 at 396 MHz
          Bus 132 MHz, IPB 66 MHz, PCI 33 MHz
   OS:    DENX Linux 2.6.24.2 "arch/powerpc" and Xenomai 2.4.2. with
          ELDK 4.2 and root filesystem via NFS

                                       Min      Max
   Xenomai user space task   (-t0):   13us    119us
   Xenomai kernel space task (-t1):    7us     82us
   Xenomai interrupt handler (-t2):    2us     47us

   Plain Linux user space task    :   31us   5749us

   cyclictest -t1 -p80 -n -i1000  :   11us     89us
   latency -p1000                 :    8us     92us


2) Board: Sequoia - AMCC PPC440EPx Evaluation Board, Rev. F, PCI=33 MHz
   CPU:   AMCC PowerPC 440EPx Rev. A at 528 MHz (PLB=132, OPB=66, EBC=66
MHz)
   OS:    DENX Linux 2.6.24.2 "arch/ppc" and Xenomai 2.4.2. with
          Ubuntu 7.04 on a USB-Disk and with a ATI Radeon 9200 card

                                       Min      Max
   Xenomai user space task   (-t0):    5us     74us
   Xenomai kernel space task (-t1):    4us     49us
   Xenomai interrupt handler (-t2):    2us     29us

   Plain Linux user space task    :    4us   1291us


As non-rt load I used "while ls; do ls /bin; done" in one and "while
./hackbench 10; do ./calibrator 400 32M cali; sleep 30; done" in a
second telnet session. The tests ran for 1.5 hours, each.

We will show the Sequoia board in action on the Embedded Workd fair in
Nuremberg next week as Xenomai demo with an Oscilloscope connected to
visualize the interrupt latencies measured with "gpioirqbench". If you
are around, feel free to visit us at Hall 12, Booth 12-246.

I have attached the "gpioirqbench" distribution. It can be adapted to
other embedded system with little effort. For further information, check
the README inside.

Wolfgang.

[1] http://www.rts.uni-hannover.de/xenomai/lxr/source/doc/txt/irqbench.txt


[-- Attachment #2: gpioirqbench-0.9.0.tar.bz2 --]
[-- Type: application/x-bzip, Size: 15141 bytes --]

Re: [Xenomai-help] gpioirqbench: measuring external interrupt latencies

[Jan Kiszka]

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

Wolfgang Grandegger wrote:
> Hello,
> 
> I'm proud to announce "gpioirqbench", a benchmark tool to measure
> external interrupt latencies. It is derived from Jan's irqbench [1] for
> the PC. Instead of using the serial or parallel port, it uses GPIO pins
> on embedded systems. It measures the time between the generation of an
> interrupt triggered by a GPIO pin and the reply by either the interrupt
> service routine, a kernel-space task or a user-space task. As reply,
> another GPIO pin will be toggled. The setup consists of two systems, the
> log host and the test target. The log host triggers the interrupt on the
> test target and measures the latency. This benchmark is primarily for
> Xenomai/RTDM, but it can also be used for plain Linux or even Linux-rt
> (with the real-time preemption patch).

Nice stuff! Still I have a few conceptual questions: :->

1. Why do you need a Xenomai measurement host? On first glance, you are
   just spinning on the reply for the RT target. Why not use plain Linux
   for this to increase portability? Most beautiful would be a pure
   userspace approach like for irqbench. What prevents this here?

2. Do you see a chance to integrate the target'S GPIO interface into the
   exiting irqbench backend? That would make it easy to merge the
   Xenomai version into the tree.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

Re: [Xenomai-help] gpioirqbench: measuring external interrupt latencies

[Wolfgang Grandegger]

Jan Kiszka wrote:
> Wolfgang Grandegger wrote:
>> Hello,
>>
>> I'm proud to announce "gpioirqbench", a benchmark tool to measure
>> external interrupt latencies. It is derived from Jan's irqbench [1] for
>> the PC. Instead of using the serial or parallel port, it uses GPIO pins
>> on embedded systems. It measures the time between the generation of an
>> interrupt triggered by a GPIO pin and the reply by either the interrupt
>> service routine, a kernel-space task or a user-space task. As reply,
>> another GPIO pin will be toggled. The setup consists of two systems, the
>> log host and the test target. The log host triggers the interrupt on the
>> test target and measures the latency. This benchmark is primarily for
>> Xenomai/RTDM, but it can also be used for plain Linux or even Linux-rt
>> (with the real-time preemption patch).
> 
> Nice stuff! Still I have a few conceptual questions: :->

I did expect them ;-).

> 1. Why do you need a Xenomai measurement host? On first glance, you are
>    just spinning on the reply for the RT target. Why not use plain Linux
>    for this to increase portability? Most beautiful would be a pure
>    userspace approach like for irqbench. What prevents this here?

Well, I'm not a hardware expert and therefore it was not obvious to me
how to connect GPIO pins to the standard PC. To avoid electrical
incompatibilities, I chose my good old TQM855L module as log host.
I agree, that this solution is rather special and that the one for
irqbench would be much better. Any ideas how to interface GPIO pins with
the PC?

> 2. Do you see a chance to integrate the target'S GPIO interface into the
>    exiting irqbench backend? That would make it easy to merge the
>    Xenomai version into the tree.

In the end I preferred to make a separated distribution, as various
parts are very hardware specific and the driver can also be built as
normal Linux character device driver.

Wolfgang.

Re: [Xenomai-help] gpioirqbench: measuring external interrupt latencies

[Jan Kiszka]

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

Wolfgang Grandegger wrote:
> Jan Kiszka wrote:
>> Wolfgang Grandegger wrote:
>>> Hello,
>>>
>>> I'm proud to announce "gpioirqbench", a benchmark tool to measure
>>> external interrupt latencies. It is derived from Jan's irqbench [1] for
>>> the PC. Instead of using the serial or parallel port, it uses GPIO pins
>>> on embedded systems. It measures the time between the generation of an
>>> interrupt triggered by a GPIO pin and the reply by either the interrupt
>>> service routine, a kernel-space task or a user-space task. As reply,
>>> another GPIO pin will be toggled. The setup consists of two systems, the
>>> log host and the test target. The log host triggers the interrupt on the
>>> test target and measures the latency. This benchmark is primarily for
>>> Xenomai/RTDM, but it can also be used for plain Linux or even Linux-rt
>>> (with the real-time preemption patch).
>> Nice stuff! Still I have a few conceptual questions: :->
> 
> I did expect them ;-).
> 
>> 1. Why do you need a Xenomai measurement host? On first glance, you are
>>    just spinning on the reply for the RT target. Why not use plain Linux
>>    for this to increase portability? Most beautiful would be a pure
>>    userspace approach like for irqbench. What prevents this here?
> 
> Well, I'm not a hardware expert and therefore it was not obvious to me
> how to connect GPIO pins to the standard PC. To avoid electrical
> incompatibilities, I chose my good old TQM855L module as log host.
> I agree, that this solution is rather special and that the one for
> irqbench would be much better. Any ideas how to interface GPIO pins with
> the PC?

Misunderstanding: I'm not talking about porting the host part to a PC, 
that is a different thing and surely involves some hardware work (unless 
the PC board already has compatible IO ports). I was talking about 
running the host part on _plain_ Linux on whatever arch providing the IO 
hardware, and maybe also running it without a kernel helper (by poking 
directly into to IO - if that is feasible). Latency-wise there is no 
need for a RTOS on the host side as you run the critical part with IRQs 
disabled.

> 
>> 2. Do you see a chance to integrate the target'S GPIO interface into the
>>    exiting irqbench backend? That would make it easy to merge the
>>    Xenomai version into the tree.
> 
> In the end I preferred to make a separated distribution, as various
> parts are very hardware specific and the driver can also be built as
> normal Linux character device driver.

I don't want to replace your distribution, I want to enhance the Xenomai 
benchmark that comes with the releases. And maybe I also want to trigger 
the development of more standard benchmark tools (compatible kernel/user 
APIs on the targets, reusable host-side tools). :)

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] gpioirqbench: measuring external interrupt latencies

[Wolfgang Grandegger]

Jan Kiszka wrote:
> Wolfgang Grandegger wrote:
>> Jan Kiszka wrote:
>>> Wolfgang Grandegger wrote:
>>>> Hello,
>>>>
>>>> I'm proud to announce "gpioirqbench", a benchmark tool to measure
>>>> external interrupt latencies. It is derived from Jan's irqbench [1] for
>>>> the PC. Instead of using the serial or parallel port, it uses GPIO pins
>>>> on embedded systems. It measures the time between the generation of an
>>>> interrupt triggered by a GPIO pin and the reply by either the interrupt
>>>> service routine, a kernel-space task or a user-space task. As reply,
>>>> another GPIO pin will be toggled. The setup consists of two systems,
>>>> the
>>>> log host and the test target. The log host triggers the interrupt on
>>>> the
>>>> test target and measures the latency. This benchmark is primarily for
>>>> Xenomai/RTDM, but it can also be used for plain Linux or even Linux-rt
>>>> (with the real-time preemption patch).
>>> Nice stuff! Still I have a few conceptual questions: :->
>>
>> I did expect them ;-).
>>
>>> 1. Why do you need a Xenomai measurement host? On first glance, you are
>>>    just spinning on the reply for the RT target. Why not use plain Linux
>>>    for this to increase portability? Most beautiful would be a pure
>>>    userspace approach like for irqbench. What prevents this here?
>>
>> Well, I'm not a hardware expert and therefore it was not obvious to me
>> how to connect GPIO pins to the standard PC. To avoid electrical
>> incompatibilities, I chose my good old TQM855L module as log host.
>> I agree, that this solution is rather special and that the one for
>> irqbench would be much better. Any ideas how to interface GPIO pins with
>> the PC?
> 
> Misunderstanding: I'm not talking about porting the host part to a PC,
> that is a different thing and surely involves some hardware work (unless
> the PC board already has compatible IO ports). I was talking about
> running the host part on _plain_ Linux on whatever arch providing the IO
> hardware, and maybe also running it without a kernel helper (by poking
> directly into to IO - if that is feasible). Latency-wise there is no
> need for a RTOS on the host side as you run the critical part with IRQs
> disabled.

A "good" processor does *not* allow to enable/disable interrupts in
user-space. Therefore a pure user-space solution with interrupts
disabled is not possible on PowerPC. My first idea was to use a software
independent hardware timer and to stop it by an external signal (in
capture mode). Nevertheless, using a standard PC as log host is still
attractive. Maybe there are some cheap GPIO-PCI cards avaliable.

>>
>>> 2. Do you see a chance to integrate the target'S GPIO interface into the
>>>    exiting irqbench backend? That would make it easy to merge the
>>>    Xenomai version into the tree.
>>
>> In the end I preferred to make a separated distribution, as various
>> parts are very hardware specific and the driver can also be built as
>> normal Linux character device driver.
> 
> I don't want to replace your distribution, I want to enhance the Xenomai
> benchmark that comes with the releases. And maybe I also want to trigger
> the development of more standard benchmark tools (compatible kernel/user
> APIs on the targets, reusable host-side tools). :)

Yep.

Wolfgang.