Thanks, Gilles. I enabled ipipe tracing but am a bit confused by what it's telling me. What I would like to do is generate a trace during the timed section of the benchmark, and not anywhere else. Looking at the output, it seems max and frozen contain traces of the longest path to date. It's not clear to me how this maps to my benchmark latencies. For example, I can sample max and/or frozen and add up the latency column and see them seemingly randomly exceed each other regardless of whether dohell is running.
Looking at http://www.xenomai.org/index.php/Xenomai:I-pipe_Tracer#API I see there are calls like xntrace_user_start and xntrace_user_stop. Is it possible to wrap the timed parts of the benchmarks with calls like this to get a more informative trace? Also, do you think the latency degradation may be due to the VIVT cache on the ARM? I'm specifically referring to additional latency due to different address spaces when switching between Linux user-mode and Xenomai kernel. Thanks again. - Eric On Tue, Feb 7, 2012 at 10:22 AM, Gilles Chanteperdrix <[email protected]> wrote: > > On 02/07/2012 01:01 AM, Eric Eric wrote: > > Hello, I've been doing some more Xenomai benchmarking lately and have come > > across what seems to be strange behavior. I'm running Xenomai 2.6.0 on a > > Beagleboard XM with kernel 2.6.37. Just running the in-kernel periodic > > task benchmark (./latency -t1) alone results in an average of 2.7uS > > latency. What is interesting is the effect of various parts of dohell: > > > > 1) If I just run unmodified dohell with only the seconds argument, the > > latency goes to about 17uS. > > > > 2) If I comment out all tests in dohell except for "dd if=/dev/zero > > of=/dev/null &", average latency goes to 3.3uS (with top indicating about > > 98% CPU usage by dd). > > > > 3) If I comment out all tests in dohell except for "while :; do cat > > /proc/interrupts; done > /dev/null 2>&1 &", average latency goes to about > > 24uS. > > > > So it seems that trapping into the Linux kernel can have a drastic effect > > on Xenomai real-time kernel latencies. > > You are drawing conclusions a bit too fast. dd also causes a lot of > trapping into the kernel. If you are interested in knowing how the time > is spent, I suggest using the I-pipe tracer. > > If you find an improvement of the I-pipe patch for your platform, we > will gladly welcome patches. > > -- > Gilles. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
