Linux for Real Time applications in accelerator control systems Linux for control systems Andreas...
-
Upload
ethan-booker -
Category
Documents
-
view
213 -
download
0
Transcript of Linux for Real Time applications in accelerator control systems Linux for control systems Andreas...
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…