Saul wrote:
Hi,
I'm trying to run a short test program, just to get into the swing
of this shiny new real-time system. I'm running Xenomai 2.1.0 on
kernel 2.6.15.6
The following program runs a busy delay in primary mode (verified by
enabling the primary mode switch warning) and calculates the time taken.
Another task is resumed and prints the time.
I get output something like this:
1: 40.017 ms
2: 40.017 ms
3: 53.357 ms
4: 53.356 ms
5: 40.017 ms
6: 40.020 ms
7: 53.355 ms
8: 40.020 ms
9: 40.017 ms
10: 53.356 ms
11: 40.020 ms
12: 40.019 ms
13: 106.710 ms
14: 40.017 ms
15: 40.018 ms ...
I assume I've done something silly but I can't find anything wrong. My
computer is a 3GHz P4. Xenomai is built-in statically, and at boot says
"Xenomai: SMI-enabled Intel chipset found, enabling SMI workaround."
It would be nice to known whether the latency test from the testsuite
has correct latency figures, so that we could rule out any SMI issue.
Anyway, the erratic execution times come and go with the smallest
changes in the program e.g. moving the delay into it's own function or
creating functions for timing the delay loop, so I wouldn't be too
surprised if the problem can't be reproduced.
What /proc/xenomai/stat says during execution btw?
Also, I found that using rt_timer_spin() instead of a real busy loop
does not have the same problem, which indicates that the simple busy
loop is in fact being interrupted during execution.
Just to rule this out, maybe you could try something along these lines:
iopl(3)
...
asm("cli");
RTIME prev_tsc = rt_timer_tsc();
my_processing();
RTIME tsc = rt_timer_tsc();
asm("sti");
Out of curiosity, I'd also be interested in looking at the assembly dump
of my_process in the working and non-working cases.
Is it a problem that I'm not explicitly destroying the tasks? They don't
linger in /proc/xenomai/sched once the program is killed. How much
is automatically cleaned up upon process exit?
Only tasks are automatically wiped out by the nucleus, basically because
they could not exist anymore after their parent process terminates.
OTOH, other objects of the native API can linger since they do not
depend on process resources, until they are explicitely destroyed or the
API module is unloaded.
#include <stdio.h>
#include <stdlib.h> // exit
#include <unistd.h> // pause
#include <sys/mman.h> // mlockall
#include <signal.h>
#include <xenomai/native/task.h>
#include <xenomai/native/timer.h>
I'll look at this on my side too.
--
Philippe.
_______________________________________________
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
