[PATCH 0/2]GPIO Loopback Benchmark Tool

chensong chensong at tj.kylinos.cn
Fri Jul 3 11:37:34 CEST 2020



On 2020年07月03日 17:21, Jan Kiszka wrote:
> On 03.07.20 08:37, chensong via Xenomai wrote:
>> In general, we use cyclictest and latency to evaluate the determinism
>> of our real
>> time system. As we know, cyclictest and latency use hrtimer to set up
>> a timer and
>> calculate jitter by comparing expected wakeup time and real wakeup time.
>>
>> Besides that, we can also use GPIO to evaluate more modules in
>> different scenarios.
>> In this case, i apply 2 GPIO ports, one is set as output, the other is
>> interrupt,
>> at the same time, connect them with a cable. Once an signal is sent
>> from output pin,
>> an interrupt will be raised in interrupt pin immediately.
>>
>> Timestamps are recorded before gpio_set_value and interrupt handler
>> respectively, the
>> diff between them is jitter.
>>
>> There is also an RT task running in the user space, which collects the
>> information and
>> output the summary at the end of the test. What's more, it also
>> records the timestamps
>> in user space, syscall overhead is included.
>>
>> Further, Making a little change will enable the tool working with
>> latency box,once a
>> signal from latency box is received in interrupt pin, the tool can
>> send a signal at
>> output pin as response. (I haven't got the latency box, so this
>> function is not in
>> place yet)
>>
>> chensong (2):
>>    demo/posix/cobalt: App of gpio loopback benchmark
>>    kernel/driver/testing: Driver of gpio loopback benchmark
>>
>>   demo/posix/cobalt/Makefile.am      |   6 +
>>   demo/posix/cobalt/gpioloop.c       | 516
>> +++++++++++++++++++++++++++++++++++++
>>   kernel/drivers/testing/Kconfig     |   7 +
>>   kernel/drivers/testing/Makefile    |   3 +
>>   kernel/drivers/testing/gpiobench.c | 288 +++++++++++++++++++++
>>   5 files changed, 820 insertions(+)
>>   create mode 100644 demo/posix/cobalt/gpioloop.c
>>   create mode 100644 kernel/drivers/testing/gpiobench.c
>>
>
> That is a valuable addition! We used to have such an interrupt benchmark
> in Xenomai 2 times or so, using a null modem connection (UART signals).
> GPIOs are more generic, though.
>
> Two things I would recommend doing differently:
>   - use RTDM GPIO device (maybe adding missing RTDM GPIO driver for
>     your targets)
>   - build benchmark not via loopback but via cross-link
>      - device-under-test receives truly asynchronous event on GPIO input
>      - reacts with flipping some GPIO output
>      - can run reaction either in interrupt handler or RT application
>        task, to cover more real scenarios
>      - latency box can also be a second device that triggers event and
>        measures reaction while having interrupts off (that's how things
>        worked in Xenomai 2)
>
> The lookback scenario is too synchronous to catch realistic latencies.
> It rather measures the performance of the event path.
actually, yes, as the ftrace log, events path contributes a lot latencies.
what's more, if the app and interrupt are not running in the cpu, IPI is 
needed, and also causes latency.
but, it can also find out latency sources under different workload as 
well as cyclictest does.
>
> Jan
>





More information about the Xenomai mailing list