MAT manual - RT config

Configuration of real-time features - proposed

Some parts of this page describe proposed functionality.

Not all of the functionality described in this section of the manual is available yet!

Introduction

All applications have requirements on timing, but for most kinds of computer programs they are not particularly strict. If a word-processor unexpectedly takes several seconds to do some operation, it is not a problem. For PLC programs, however, they are often very important. The mechanisms used to deal with the timing requirements are collectively called "real-time".

MatPLC modules will be able to run in one of three modes: normal, soft real-time and hard real-time. Different modules can run in different modes at the same time.

normal: No action taken to guarantee response time. This is suitable for demos and low-priority monitoring, but not much else. This is the default. Status: available now.
soft real-time: The module has absolute priority over other programs, but not over the operating system itself, so there are no guarantees. This is the best that can be done with a generic linux kernel. Status: available now.
hard real-time: Provides timing guarantees, but requires a special kernel modules, and some care in writing the program. (Note: this does not necessarily mean that it's fast; merely that the timing is accurate when it needs to be.) Status: not yet implemented.

The MatPLC can be compiled in two ways: N/S, where Normal and Soft-RT is available, and N/S/H where all three are available but the special kernel is required. The default is N/S.

Real-time and synch

There is some interaction between the real-time stuff and synch; fortunately, the rule is simple: never make a synch arrow from a low priority module to a high priority one.

You can synch between equal-priority modules, and you can make synch arrows from high priority modules to lower priority ones; but never the other way around.

Modules

In general, there's no change to a module regardless of whether it's running normal, soft real-time or hard real-time

However, there are some modules which may not run in hard real-time mode, because of the nature of their work. For instance, if a module needs to write to a file, it has to be normal or soft real-time. For the generic and specific modules, this is noted in the manual where appropriate. For custom modules, the module-writer needs to be careful: if any system calls are used, the module may not be run in hard real-time mode.

Swapping

As you can imagine, being swapped out to disk will give a module a sizeable timing glitch. The first step, then, is to make sure it doesn't happen. The downside is that only programs that run as root can do this. (FIXME is suid-root enough? capabilities?)

The setting rt_memlock in the [PLC] section controls this. When it's 1, all modules will be locked into memory. (Due to the way the MatPLC works, it's not really sensible do this on a per-module basis.)

When compiled N/S/H, this option is always on (and only root can start modules).

Status: this setting is implemented but not tested

Soft-RT

The setting rt_softpri controls this. This is a per-module setting, with a default in the [PLC] section. When it's greater than 0, the module is made soft-rt with the given priority. The allowable range is 1-99, with 99 being the highest.

Only modules started by root will be able to go soft-rt.

Status: this setting is implemented but not tested

Low-latency kernels

The timing performance of Normal and Soft-RT can be improved by using a low-latency kernel. Such a kernel switches between processes more often than the generic one, thus reducing the latency in any one process. The cost is that all this switching does reduce overall performance slightly, which is why this tuning parameter is set differently for general purpose kernels.

Similarly, different versions of the kernel have different default schedulers, which have different features. For instance, see this article on LinuxDevices.com about the linux 2.6 improvements.

Hard-RT

When MatPLC is compiled N/S/H, it uses RTAI LXRT to obtain hard-realtime. Modules can still run in normal and soft-RT, but they will all be LXRT tasks, which means that they must be started by root and memory locking is always on.

The settings are FIXME

The caveats are FIXME (syscalls drop the module to Soft-RT, debugging not available, etc)

Status: this functionality is not yet implemented

Better than LXRT MatPLC

MatPLC, like any general purpose product or framework, is a compromise between various aspects. If timing accuracy is paramount, one will have to skip the niceties and write a (hopefully small) part of the application as a kernel-space hard-RT task doing direct I/O. Writing and debugging such code is beyond the scope of this manual.

Much tighter results still can be obtained by pushing the speed-sensitive parts to FPGA or other hardware; John Storrs's LME Craftsman project (FIXME - add URL) takes this approach, giving nice, clean, jitter-free oscilloscope traces.

As far as the MatPLC is concerned, these would simply be "smart I/O". For instance, the MatPLC could command direction, speed and number of steps, and the kernel-task or FPGA would generate the stepper motor train.

$Date: 2004/01/05 05:02:20 $