1 / 28

Linux for Real Time applications in accelerator control systems

Linux for Real Time applications in accelerator control systems. 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?.

bjeff
Download Presentation

Linux for Real Time applications in accelerator control systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Linux for Real Time applications in accelerator control systems Andreas Steinbacher 16.11.09

  2. 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

  3. 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.

  4. Standard CS architecture: Supervisory Control System Presentation Tier (1) Network ProcessingTier (2) Network Equipment Tier (3) Accelerator Control System Beam Control System Network Frontend Tier (4)

  5. 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“

  6. Soft Real-Time vs. Hard Real-Time: Soft RT Error Latency Hard RT Error Latency

  7. What RT do we need?

  8. 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.“

  9. What parameters do we need? • Interrupt latency -> maxlat, dist… • Periodic tasks -> maxlat, dist, jitter

  10. How do we test? • Defined Scheduler - FIFO/RR • Defined Priority – 0,10,49,90,99 • Defined Load – ltp´s loadgen

  11. 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 program kill_fasync(&inputdevice_async_queue, SIGIO, POLL_IN); return IRQ_HANDLED; } • ioctl - I/O control (triggered by user program) static int skeleton_ioctl(structinode *inode, struct file *file, unsigned int cmd, unsigned long arg) { ….. outb_p(255, BASEPORT);outb_p(0, BASEPORT); //All high, all low

  12. 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 }

  13. Results: Round trip time

  14. Results: Round trip time

  15. Results: Round trip time

  16. Results: Round trip time

  17. Results: Round trip time

  18. Results: Round trip time

  19. Results: Round trip time

  20. Results: Round trip time

  21. Results: Round trip time

  22. 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.

  23. Results: Periodic tasks RT

  24. Results: Periodic tasks NON RT

  25. Results: Periodic tasks

  26. 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.

  27. Outlook: • Paper on RT_Preemptive performance • Test net socket RT performance • Create an application to reconstruct the exact MA use – case.

  28. End of Presentation: The time is gone The song is over Thought I'd something more to say…

More Related