HOWTO: Build an RT-application

From RTwiki
(Difference between revisions)
Jump to: navigation, search
(Why is X86 not the ideal RT platform?)
Line 27: Line 27:
 
* On-demand CPU scaling: creates long-latency events when the CPU is put in a low-power-consumption state after a period of inactivity. Such problems are usually quite easy to detect. (e.g. On Fedora the 'cpuspeed' tool should be disabled, as this tool loads the ondemand scaling_governor driver)
 
* On-demand CPU scaling: creates long-latency events when the CPU is put in a low-power-consumption state after a period of inactivity. Such problems are usually quite easy to detect. (e.g. On Fedora the 'cpuspeed' tool should be disabled, as this tool loads the ondemand scaling_governor driver)
 
* VGA Console: During RT behavior of the system the VGA Console must be left untouched. Nothing may be written to that console, also printk's are not allowed. This VGA console can cause very large latencies, up to more than a millisecond. It is better to use a serial console and have no login shell on the VGA console. Also SSH or Telnet sessions can be used. The 'quiet' option on the kernel command line could also work if login in on the console is disabled.
 
* VGA Console: During RT behavior of the system the VGA Console must be left untouched. Nothing may be written to that console, also printk's are not allowed. This VGA console can cause very large latencies, up to more than a millisecond. It is better to use a serial console and have no login shell on the VGA console. Also SSH or Telnet sessions can be used. The 'quiet' option on the kernel command line could also work if login in on the console is disabled.
 
===Negative impact VGA Console===
 
  
 
==Writing hard realtime applications==
 
==Writing hard realtime applications==

Revision as of 21:25, 16 December 2006

Contents

Intro

Authors

Remy Bohmer (Software Engineer Linux RT platform)

Revision

Revision History
Revision 1 2006-12-16
Draft / Work in progress

Abstract

This document describes the steps to writing hard realtime linux programs while using the Realtime Preemption Patch. It also describes the pitfalls that destroy the realtime responsiveness. It focusses on x86, as this is currently the most mature architecture.

Common Pitfalls

Hardware causes of ISR latency

A good Realtime behaviour of a system depends a lot on low latency interrupt handling. Taking a look at the X86 platform, it shows that this platform is not really designed for RT usage. Several mechanisms cause ISR latencies that can run into the 10's of microseconds. Knowing them will enable you to make the best design choices on this platform to enable you to get rid of the negative impact.

  • DMA busmastering: Bus mastering events can cause long-latency CPU stalls of many microseconds. It can be generated by every device that uses DMA, such as SATA/PATA/SCSI devices and even network adapters. Also video cards that insert wait cycles on the bus in response to a CPU access can cause this kind of latency. Sometimes the behavior of such peripherals can be controlled from the driver, trading off throughput for lower latency. The negative impact of busmastering is independant from the chosen OS, so this is not a unique problem for Linux-RT, even other RTOS-es experience these type of latency!
  • On-demand CPU scaling: creates long-latency events when the CPU is put in a low-power-consumption state after a period of inactivity. Such problems are usually quite easy to detect. (e.g. On Fedora the 'cpuspeed' tool should be disabled, as this tool loads the ondemand scaling_governor driver)
  • VGA Console: During RT behavior of the system the VGA Console must be left untouched. Nothing may be written to that console, also printk's are not allowed. This VGA console can cause very large latencies, up to more than a millisecond. It is better to use a serial console and have no login shell on the VGA console. Also SSH or Telnet sessions can be used. The 'quiet' option on the kernel command line could also work if login in on the console is disabled.

Writing hard realtime applications

Step 1: Preventing Pagefaults

Step 2: Memory Locking

Step 3: Is Dynamic Memory allocation possible?

Step 4: The use of the filesystem

Personal tools