Linux for Real Time applications in accelerator control systems

Linux for control systems Andreas Steinbacher 16.11.091

Agenda

• Why Linux?• Standard CS architecture• What is Real Time ?• What RT do we need ?• Real time Operating Systems• What parameters do we need ?• How do we test ?• The kernel module• The user program• Results

Why Linux?

• Same OS for all control system tiers• Linux is open, you know how things tick inside,

and you can change them.• Real Time capabilities look promising,

experience,- but no data exist within CERN.

Standard CS architecture:

Frontend Tier (4)Frontend Tier (4)

Equipment Tier (3)Equipment Tier (3)

ProcessingTier (2)ProcessingTier (2)

Presentation Tier (1)Presentation Tier (1)Supervisory Control System

Network

Network

Accelerator Control System

Beam Control System

Network

What is realtime?

• Soft Real Time:• System performs not always within limits

consequences are not catastrophic.• System is normally „fast enough“, errors can be

detected in time.• VOIP, Videoconferences,

• Hard Real Time:• Crossing limits causes catastrophic consequences.• System guaranties to be in time.• Pacemaker, Automotive systems (ABS,ESP, Ignition)

• None Real Time:• No limits or consequences. „postcard“

Soft Real-Time vs. Hard Real-Time:

Latency

Latency

Err

or

Err

or

Soft RT

Hard RT

What RT do we need?

Real time operating systems

• VxWorks, LynxOS, RTEMS, QNX, also: DOS .• And many more…

http://en.wikipedia.org/wiki/List_of_real-time_operating_systems

• RT_Preemptive

„The RT-Preempt patch converts Linux into a fully preemptible kernel.“

What parameters do we need?

• Interrupt latency -> maxlat, dist…• Periodic tasks -> maxlat, dist, jitter

How do we test?

• Defined Scheduler - FIFO/RR• Defined Priority – 0,10,49,90,99• Defined Load – ltp´s loadgen

The kernel module• Registers an interrupt handler:

ret = request_irq(PARALLEL_PORT_INTERRUPT, &interrupt_handler,IRQF_DISABLED, "parallelport", NULL);

• Interrupt handler (triggered by stimulus pulse):

static int interrupt_handler(void){//send signal to user programkill_fasync(&inputdevice_async_queue, SIGIO, POLL_IN);return IRQ_HANDLED;}

• ioctl - I/O control (triggered by user program)static int skeleton_ioctl(struct inode *inode, struct file *file,

unsigned int cmd, unsigned long arg) {….. outb_p(255, BASEPORT);outb_p(0, BASEPORT); //All high, all low

The user program• Registers a Signal handler

int InstallMySignalHandler(void){. . . . . . . . .

sa.sa_handler = mySignalHandler;sigaction(SIGIO, &sa, &osa); //register handler

return 0;}

• Signal Handler (triggered by kernel module)

static void mySignalHandler (){ioctl(fd, CASE4, NULL); //tell driver to generate a pulse}

Results: Round trip time

Results: Round trip time

Results: Round trip time

Results: Round trip time

Results: Round trip time

Results: Round trip time

Results: Round trip time

Results: Round trip time

Results: Round trip time

SWAVE – Periodic tasks

• clock_nanosleep - high resolution sleep with specifiable clock (ADVANCED REALTIME)

/* wait untill next shot */ clock_nanosleep(0, TIMER_ABSTIME, &t, NULL);

If the flag TIMER_ABSTIME is set in the flags argument, the clock_nanosleep() function shall cause the current thread to be suspended from execution until either the time value of the clock specified by clock_id reaches the absolute time specified by the rqtp argument, or a signal is delivered to the calling thread and its action is to invoke a signal-catching function, or the process is terminated. If, at the time of the call, the time value specified by rqtp is less than or equal to the time value of the specified clock, then clock_nanosleep() shall return immediately and the calling process shall not be suspended.

Results: Periodic tasks RT

Results: Periodic tasks NON RT

Results: Periodic tasks

Conclusion

• From the collected data it can be said that RT_Preemptive is not suitable for a hard Real Time system. Even though outliners appear only <=1 time in a million, they disqualify RT_Preemptive from being hard RT.

• Also it can be claimed that RT_Preemptive offers exceptional performance for periodic tasks and IO-driven applications thus qualifying it to be suitable for soft RT with reserves for error avoidance or correction.

• Development side of view: It´s flexible!• Hard RT should be delegated to hardware.

Outlook:

• Paper on RT_Preemptive performance• Test net socket RT performance• Create an application to reconstruct the exact MA

use – case.

End of Presentation:

The time is goneThe song is over

Thought I'd something more to say…