# Copyright (C) 2005-2017 The RTAI project
# This [file] is free software; the RTAI project
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.


	REMARKS-SUGGESTIONS ABOUT CONFIGURING LINUX AND RTAI

< LINUX kernel related >
- Under SMP set the number of CPUs equal to the real ones and have it matched in RTAI,
  no hyperthreading intended (see below)
- Some peripherals, e.g. video cards, may stall CPUs attempting to access IO space.
  Verify "what ifs" related to graphic acceleration, likely better if disabled.
  Consider also if X term usage is really needed. If possible avoid it, especially
  in production work.
- LINUX use of DMA can add latency, especially when it is supported in burst mode.
- Cached memory disruption can add significant latencies, till the cache becomes hot
  again, experienced first hand after a far jump in the code and data in a digital
  controller.
- Power management, see CONFIG_CPU_FREQ and CONFIG_CPU_IDLE below; on portables 
  battery management too.
- Recent Intel SpeedStepping and Boosting.
- Disable AUDITSYSCALLS.
- Disable CPU_FREQ.
- Disable CPU_IDLE and INTEL_IDLE, or boot with "intel_idle.max_cstate=0". If you
  want to be sure to have a never sleeping CPU execute, at the lowest priority, 
  your own, per cpu, idle task, i.e. one just doing "while(1);".
- Disable APM and ACPI_Processor, but not everything related to power management.
  Take also into account that without ACPI enabled you might not see more than 
  a single CPU.
- Do not enable IPIPE legacy support. As a safety measure against such a choice, 
  RTAI build is inhibited at the making of rtai_hal.ko.
- Do not disable USB, but just any legacy support, possibly in the BIOS also. Once
  upon a time USB was a source of high RTAI latencies. Now that should happen with
  just legacy support enabled. 
- Try to configure the CPU type to be as close as possible to the one you have.
- If unsure on the CPU to choose, care of setting one featuring the Time Stamp Clock 
  (TSC), which means no 486 and "false" i586, since generic INTEL i586 compatibles
  often do not have a TSC, while true INTEL ones do have it.
- If you are using a UniProcessor (UP) compile RTAI against a UP configured kernel.
  In fact RTAI compiled for SMP may not work when used on a UP machine. An issue 
  to be fixed, sooner or later. In any case having everything UP for UP is always
  the more efficient solution.
- If it is of no interest to you, disable any kernel debug support. Generally speaking,
  most RTAI users are not expected to debug the kernel, so it is suggested to always do 
  so for production work. In any case, even if there should be no trouble in keeping it,
  except for some overhead more and an increase of latency here and there, it may happen
  that tracing could affect RTAI parts having some commonality with the kernel, e.g.
  though trace points missing symbols. If that happens you should either disable, at 
  least, the "Kernel function tracer" option, in "Kernel hacking", "Tracers".
- If you witness a stack protector crash, disable stack protector support, at the
  bottom of the kernel config General Setup. There are 3 choices, "None" will work
  with RTAI for sure. It is possible that the "Regular" one could also be OK, while
  "Strong" will fail, always.


< RTAI related >
- Even if RTAI can work with hyperthreading enabled, such an option is deprecated
  as a possible cause of latency; in any case try and verify if it is acceptable,
  with your hardware and for your applications.
- Any initialization of the device drivers, or anything related to the hardware,
  may lead to high latencies, e.g., but not always. doing "startx &" while a real
  time application is running. Once it is started there should be no major problems.
  If the truoble persists and you really need X, concurrently with your RTAI tasks,
  try disabling hardware graphic acceleration. The best latencies usually come with
  no graphic application running.
- A sizable part of the latency you see in RTAI hard timed programs can mature as 
  an interrupt latency, little can be done to avoid that. Recall that, for shared pieces
  of hardware, e.g APIC, LINUX is left with the capability of using a few hard interrupts
  disable/enable. Moreover even if the processing of LINUX interrupts, during hard real
  time RTAI activities is delayed, they must be pended to be processed later on anyhow.
  A thing which requires keeping interrupts disabled for a while, hopefully short.
- If SMI is enabled and latencies are high, often appearing periodic also, use the 
  RTAI tools to monitor and, possibly, fix it. See READMEs in "base/arch/x86/calibration".

Finally, I have found it interesting what shown at:
relacs.sourceforge.net/plugins/rtaicomedi