heres another try.

contains some speculative explanations that perhaps warrant rewording.

The regular reader will also detect some prose poached from this ML ;-)
--- TROUBLESHOOTING     (revision 935)
+++ TROUBLESHOOTING     (working copy)
@@ -6,6 +6,46 @@
+Q: Which CONFIG_* items are latency killers, and should be avoided ?
+A: Heres an enumeration.  Several of these are discussed in greater
+detail later.  Feel free to verify that these cause latencies to
+explode (xeno-test runs testsuite/latency 3 different ways), but keep
+in mind that before you rely on the numbers, you must create workloads
+that will excersize all the hardware used for your RT application.
+CONFIG_CPU_FREQ: This allows the CPU frequency to be modulated with
+workload, but many CPUs change the TSC counting frequency also, which
+makes it useless for accurate timing when the CPU clock can change.
+ACPI_PROCESSOR: ACPI is a complex BIOS functionality, and BIOS code is
+never written with RT-latency in mind.  If enabled, this BIOS code can
+be invoked at a pseudo-SMI priority, which breaks the rule that
+adeos-ipipe must be in charge of such things.  DISABLE_SMI doesnt help
+here (more later).
+PM & APM: Linux power management features also use the BIOS, so ACPI
+comments apply here too.
+Q: How do I adequately stress-test ?
+A: xeno-test has a very basic workload generator, whose main virtue is
+that its nearly universally available.
+    dd if=/dev/zero if=/dev/null
+You can change the input device (-d /dev/hda1) to get real device
+activity and interrupts, and/or -w 4 to run more workload tasks.  For
+more thorough testing, use -W <your-script>.
+If you are looking for real heavy load: cache benchmarks tend to
+stress your system most, for
+example. Combine them with heavy i/o load (flood ping etc.).
 Q: My user-space application has unexpected latencies which seem to
 appear when transitioning from primary (Xenomai) to secondary (native
 Linux) real-time modes. Why?
--- README.INSTALL      (revision 935)
+++ README.INSTALL      (working copy)
@@ -74,12 +74,14 @@
 Once the target kernel has been prepared, all Xenomai configuration
 options are available from the "Real-time subsystem" toplevel menu.
-Once configured, the kernel should be built as usual.
+There are several configure options that cause large latencies; they
+should be avoided.  The TROUBLESHOOTING file identifies them and
+explains the issues with their use.  Once configured, the kernel
+should be built as usual.
-It might be a good idea to put all the output into a different build
-directory as to build from from linux source several targets. For each
-target add O=../build-<target> to each make invocation. See section 2.2 
-for an example.
+If you want several different configs/builds at hand, you can reuse
+the same source by adding O=../build-<target> to each make
+invocation. See section 2.2 for an example.
 In order to cross-compile the Linux kernel, pass an ARCH and
 CROSS_COMPILE variable on make command line. See sections 2.2, 2.3 and
@@ -105,7 +107,9 @@
 albeit the kernel has been compiled with CONFIG_X86_TSC disabled would
 certainly lead to runtime problems if uncaught, since Xenomai and the
 application would not agree on the high precision clock to use for
-their timings.
+their timings.  Furthermore, most of these issues cannot be probed for
+during compilation, because the target generally has different
+features than the host, even when theyre the same arch (ex 386 vs 686)
 In order to solve those potential issues, each Xenomai architecture
 port defines a set of critical features which is tested for
@@ -126,8 +130,8 @@
 kernel built with CONFIG_X86_TSC set, since the x86-tsc option's
 binding is strong.
-1.3.2 Generic options
+1.3.2 Generic configure options
 NAME                 DESCRIPTION                     [BINDING,]DEFAULT(*)
@@ -137,15 +141,17 @@
 --enable-debug       Enable debug symbols (-g)       disabled
 --enable-smp         Enable SMP support              weak,disabled
-1.3.3 Arch-specific options
+1.3.3 Arch-specific configure options
 NAME                DESCRIPTION                      [BINDING,]DEFAULT(*)
 --enable-x86-sep    Enable x86 SEP instructions      strong,disabled
-                    for issuing syscalls
+                    for issuing syscalls.
+                   You will also need NPTL
 --enable-x86-tsc    Enable x86 TSC for timings       strong,enabled
+                   You must have TSC for this.
 --enable-arm-arch   Define version of the target     strong,"4"
                     ARM core architecture
@@ -254,7 +260,7 @@
 2.4 Building for the Blackfin
-The Blackfin is a MMU-less, DSP-type architecture running
+The Blackfin is an MMU-less, DSP-type architecture running
 $ $xenomai_root/scripts/ --arch=blackfin \
Xenomai-core mailing list

Reply via email to