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. Why is this? Shouldn't a timer-driven runnable real-time Xenomai kernel task require the same preemption latency regardless of whether Linux is busy or not? And it's not just that Linux processes are loading the CPU (this happens in case 2 with relatively little effect on latency), but that it's the act of trapping into the kernel that causes the latency. Any ideas why this is the case? Thank you very much. - Eric
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
