Add back a 1s warm-up time, making sure not to include the delta
values collected during this period in the histogram distribution this
time.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>
We may not get back to the test sitter upon signal (SIGINT/SIGALRM),
so move the code parsing the last data bulk behind the sigwait() call
instead.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>
This mode measures the delay between the moment a synthetic interrupt
is posted from the oob stage and when it is eventually received by its
in-band handler. When measured under significant pressure, this gives
the typical interrupt latency experienced by the in-band kernel due to
local interrupt disabling.
Therefore, this is an in-band only test which measures IRQ latency
experienced by the common kernel infrastructure, _NOT_ by EVL.
Measurement is requested with '-s' option.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>
Using [SCHED_FIFO, 98] for running the responder thread will work for
both EVL and native preemption configurations (i.e. GPIO mode). On the
latter, it won't compete with high-priority housekeeping threads
running in kernel space (prio 99) which is recommended and saner. On
both, this leaves lower priority levels for common application-level
threads.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>
We have been dealing properly with cells having no sample logged for
many moons. There is no reason to increment all cell counts anymore.
This makes the overall sample count consistent with the sum of all
cell counts.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>
This is a general fix addressing several issues in the retrieval of
histogram data from latmon, which reverts #6b2425d8 in the same move:
- use a safe socket send loop in order to cope with partial writes on
the latmon side.
- drop the very notion of warmup time, the system must be ready to
respond with no delay or preparation, and the average figures won't
be affected over long enough runs anyway.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>
Losing the whole result log upon network error communicating with
latmon is very annoying, especially when this happens at the very end
of an overnight test. Since we have a TCP connection, we can trust the
results received so far, so dump them to the result file regardless.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>
Since ABI 23, the core is able to channel T_WOSS, T_WOLI and T_WOSX
error notifications through the offender's observable component if
present.
Convert all SIGDEBUG_xxx cause codes to the new EVL_HMDIAG_xxx naming,
so that we have a single nomenclature for these errors regardless of
whether threads are notified via SIGDEBUG or their observable
component.
The API rev. is bumped to #17 as a result of these changes.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>
Since core ABI 21, users can decide whether a new element should be
made public or private depending on the value of clone flags added to
the new long form of all element creation calls, i.e. evl_create_*().
All evl_new_*() calls become a shorthand for their respective long
form with reasonable default arguments, including private visibility.
As a shorthand, libevl also interprets a slash character leading the
name argument passed to these services as an implicit request for
creating a public element. In other words, this is the same as passing
EVL_CLONE_PUBLIC in the clone flags.
A public element appears as a cdev in the /dev/evl hierarchy, which
means that it is visible to other processes, which may share it. On
the contrary, a private element is only known from the process
creating it, although it does appear in the /sysfs hierarchy
regardless.
e.g.:
efd = evl_attach_self("/visible-thread");
total 0
crw-rw---- 1 root root 248, 1 Apr 17 11:59 clone
crw-rw---- 1 root root 246, 0 Apr 17 11:59 visible-thread
or,
efd = evl_attach_self("private-thread");
total 0
crw-rw---- 1 root root 248, 1 Apr 17 11:59 clone
Signed-off-by: Philippe Gerum <rpm@xenomai.org>
These changes fix up the argument passed to the core system calls in
order to abide by the new ABI allowing 32bit applications to issue
requests to 64bit kernels.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>
This won't change anything EVL-wise, but this minimizes the risk of
conflicting thread priorities when running the in-band GPIO test over
a native preemption kernel.
Replace -a (abort-on-switch) with -K (keep-going upon
switch). Aborting becomes the default setting upon unexpected switch
to in-band mode of the responder thread, in order to prevent any
misinterpretation of broken results obtained from a broken set up.
Let the user generate any background noise as/if required. We simply
cannot approximate the typical load of the target system in a reliable
manner with a fixed dd-like loop.
Measure response time to GPIO events sent by a remote Zephyr-based
latency monitor (latmon). This monitor collects then sends the latency
data over a network connection to the latmus front-end which displays
the results received:
[Linux device under test running latmus] <--+
|
^ | (GPIO ack) |
| | | TCP/IP network connection
| | | (control & data samples)
| (GPIO pulse) v |
|
[Zephyr-based device running latmon] <--+
The generic latency monitor code running the measurement loop is
available from the zephyr/ directory. This support comes with a Zephyr
device tree patch for enabling this monitor on NXP's FRDM-K64F
development board.
This Linux-side tool is designed to echo the GPIO signals issued from
a remote board, which in turn measures the response time. The code has
been validated using a Linux-based rpi3b running gpio-echo, and a
Zephyr-based FRDMk64f board measuring the response time.
The current version of the Zephyr code is available in the zephyr/
subdirectory in patch format. This code is maintained at:
https://github.com/ldts/zephyr.git, branch evl-latency
For instance, GPIO23 can be used to receive test signals on rpi3b and
GPIO24 to respond to them.
gpio-echo is realtime capable (via EVL) or non-realtime capable
(standard Linux behaviour) - it depends on how you run it.
$ gpio-echo -n gpiochip0 -o 23 -t 24 -O -T -f
Once that process is started (and the necessary cabling is done) start
this Zephyr program, get the console and follow the instructions.
Connections:
-------------
Zephyr - FRDMk64F: Linux - rpi3b
PIN 20 (PTE-24) ---------------- PIN 16 (GPIO 23)
PIN 18 (PTE-25) ---------------- PIN 18 (GPIO 24)
Signed-off-by: Jorge Ramirez-Ortiz <jro@xenomai.org>
Philippe Gerum