1 / 57

RTDroid : toward building dynamic real-time systems

RTDroid : toward building dynamic real-time systems. Lukasz Ziarek University at Buffalo Dagstuhl Seminar: Resource Bound Analysis. Collaborators. Ethan Blanton – Fiji Systems Inc Jan Vitek – Northeastern Karthik Dantu – UB Steve Ko - UB. Yin Yan (Ph.D. Student)

rollo
Download Presentation

RTDroid : toward building dynamic real-time 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. RTDroid: toward building dynamic real-time systems Lukasz Ziarek University at Buffalo Dagstuhl Seminar: Resource Bound Analysis http://rtdroid.cse.buffalo.edu

  2. Collaborators • Ethan Blanton – Fiji Systems Inc • Jan Vitek – Northeastern • KarthikDantu – UB • Steve Ko - UB • Yin Yan (Ph.D. Student) • Many masters students http://rtdroid.cse.buffalo.edu

  3. Motivations • Open source project • Well-defined APIs • Rich on-device peripherals How can we write a real-time application on Android, while still leveraging Android’s existing functionality? http://rtdroid.cse.buffalo.edu

  4. Cochlear Implant Device Cochlear implant as a motivating example • An external device for audio recording and processing • Implanted electrodes stimulate the cochlea http://rtdroid.cse.buffalo.edu

  5. Architecture of Cochlear Implant Application on Android UI Activity Audio Recorder (Service) Periodic Audio Recording Task Volume Receiver Audio Processor (Service) Button Listener MsgHandler Periodic Audio Processing Task 8 ms UI Handler Output Simulator (Broadcast Receiver)

  6. Sound Processing Latency Duration of 12% of audio processing releases is longer than 8 ms. Cochlear Implant: Audio Processing Duration

  7. What Is Missing in Android? Lack of real-time expressiveness • Can’t prioritize the execution of application components • Can’t specify real-time configuration Lack of real-time communication • No priority awareness for message/intent delivery • No protection mechanism for cross-context communication Lack of memory guarantees Non Real-time components Real-time components UI Activity Audio Recorder (Service) Periodic Audio Recording Task Volume Receiver Audio Processor (Service) Button Listener MsgHandler Periodic Audio Processing Task UI Handler Output Simulator (Broadcast Receiver)

  8. A View Of Android Applications No Real-time Expressiveness FIFO Message Passing Fair System Services Application Framework Constructs And APIs System Services Runtime Unpredictable Garbage Collection No Support for RT POSIX Extension Bionic Dalvik/ART Fair Scheduling Out of Memory Killer Kernel Forced GC Power Management Linux with Android Modifications Android Stack

  9. Proposed Architectures for Real-time Android Applications RT Apps Applications RT Apps Application Framework Application Framework Libraries Core Libraries Core DalvikVM DalvikVM Linux Kernel Linux Real-time Real-time Hypervisor Completely Isolated

  10. Proposed Architectures for Real-time Android Applications Applications Application Framework Application Framework Libraries Core RT JVM Libraries Core DalvikVM ExtendedDalvikVM Linux Real-time Linux Real-time Lower Latencies Best Effort Interactions Unclear ?

  11. RTDroidArchitecture • Programing Model • Validation Mechanisms Applications Application Framework Redesigned Components • Redesigned Message Passing • Redesigned System Services Runtime • Real-time Garbage Collection • POSIX RT Extension • RTSJ Libraries Extended Bionic Bionic Dalvik/ART Fiji MVM • Priority Based Scheduling • PIP Locks Linux with Android Modifications RT Linux or RTEMS RTDroid Stack http://rtdroid.cse.buffalo.edu

  12. Components and System Services http://rtdroid.cse.buffalo.edu

  13. Redesigned Components Application Framework Constructs and APIs Runtime System Services RT Handler RT AlarmManager RTSJ RT SensorManager RTDroid RT SoundManager

  14. Why Looper and Handler? • One of the central message-passing mechanisms. • All Android apps unknowingly use Looper-Handler. • Most of the system services use Looper-Handler. http://rtdroid.cse.buffalo.edu

  15. Looper and Handler • Looperis a per-thread message loop. • Handler processes messages. • A thread uses Handler.send() to send a message. Receiver Thread Sender Thread Looper Message Queue Handler Handler Ref (provides send()) … Message Message

  16. What’s Wrong with Looper/Handler in a Real-time Context? Message Queue Looper … RT msg msg N msg 1 Messages are processed FIFO or by client-specified time Handler No guarantee on message delivery RT client thread Non-RT client thread Non-RT client thread http://rtdroid.cse.buffalo.edu

  17. RTLooperand RTHandler Msg Queue Msg Queue Looper (Non-RT Thread) RT Looper (RT Thread) msg1 msg1 … … msg n msg n RT Handler Handler instance Handler instance RT client thread Non-RT client thread Non-RT client thread … http://rtdroid.cse.buffalo.edu

  18. Android Sensor Manager APIs Sensor Manager Application Enable/disable hardware Accelerometer Sensor Event Listener Configure sampling rate Gyroscope Subscribe to sensor events … Magnetometer http://rtdroid.cse.buffalo.edu

  19. How Does Android’s Sensor Manager Work? Sensor Event Listener • Sensor • Manager Input Event HAL • Sensor • Service Sensor Thread Native SensorManager Sensor Fusion Sensor Thread Event Queue Kernel System Runtime Framework Application http://rtdroid.cse.buffalo.edu

  20. What Happens In a Real-Time Context? • One application is listening on two sensors: • Accelerometer with higher priority • Gyroscope with lower priority Application Android Framework Kernel Accelerometer Data Gyroscope Data Shared delivery path and unbound delivery time http://rtdroid.cse.buffalo.edu

  21. RT Sensor Manager • Event-driven architecture • Prioritize the delivery procedure of sensor events • Multiple listeners with different sampling rates http://rtdroid.cse.buffalo.edu

  22. RT Sensor Manager Listener 3 Listener 1 Listener 2 Listener 4 Delivery Thread 1 Delivery Thread 4 Delivery Thread 3 Delivery Thread 2 Listener’s rate and priority Orientation Event Accel Events Gyro Events The highest priority of its listeners Sensor Fusion Accel Polling Thread Gyro Polling Thread Orientation Polling Thread /dev/input/ event6 /dev/input/ event1

  23. Remaining Questions • Multi-app execution • Real-time Android Programming model • Static Memory Guarantees http://rtdroid.cse.buffalo.edu

  24. Multi-app Execution http://rtdroid.cse.buffalo.edu

  25. Android: Application Isolation & Communication • One VM per application • Virtual Memory • Each application has its own PID, UID for isolation App A App B System Server App Components App Components ActivityManager Activity Thread ServiceManager ART Activity Thread ART Linux Kernel Binder Driver

  26. Multi-Tasking VM (MVM) All applications run in a single VM. The VM runs each application in an isolation unit called a partition, but all applications run as a single process (the same memory space). How does MVM provide isolation? • Separated Class loading (Fiji uses lightweight VMs) • Dynamically manage Memory boundaries • Statically Configured Heap Memory http://rtdroid.cse.buffalo.edu

  27. Time Partitions in MVM • MVM slice manager: • Fixed-length time slice for each partition • Partition initiation, suspension, resume, termination • Two approaches for thread scheduling: • Direct OS scheduling vs partition dispatcher with a thread pool

  28. Communication in MVM • Shared address space provides flexibility • Wait free pair transactions • One way communication channel over primitives • CAS and replicas • Priority Rollback Protocol • Inspired by transactional memory • Similar tracking structures • write buffers, undo log • The lock itself provides concurrency control http://rtdroid.cse.buffalo.edu

  29. Programming Model http://rtdroid.cse.buffalo.edu

  30. Can we write an App with RTDroid? Applications • RT-Looper and RT-Handler • RT Alarm Manager • RT Sensor Manager • What else is missing? Application Framework Runtime Extended Bionic Fiji VM Linux with Android Modifications RT Linux or RTEMS http://rtdroid.cse.buffalo.edu

  31. Programming Model Android Apps RT app Android Applications RTDroid Applications • Declarative real-time components • Real-time communication channel • Memory guarantees • region-based allocation • Design principles: • Retains a similar style of Android • Minimizes code complexity in application • Enables application validation with real-time configuration prior to execution Android Framework RTDroidFramework Dalvik / ART Fiji Java VM Android Linux Kernel with RT Patch

  32. Declarative Real-Time Components <service name="pkg.ProcessingService”priority="79"> <memSizespersistent="1M” release="1M" /> <periodic-task name="procTask“ priority="79"> <release start="0ms" periodic="8ms" /> </periodic-task> … </service> Service + onStartCommand() + onBind() + onCreate() + onDestroy() BroadReceiver + onReceive(…) • Real-time components • RT service • RT broadcast receiver • Periodic task • Application manifest • Priority • Timing parameters • Memory bounds RealtimeReceiver + onClean() RealtimeService + onPause() PeriodicTask + onRelease()

  33. Real-Time Communication Channels <channel name=“msghandler” type=“msg-passing”> <!-- message delivery and processing policies --> </ channel> • Four types of channels • RT message passing channel • RT intent broadcasting channel • RT bulk data transfer channel • Cross-context channel • Communication policies • Message delivery order • Component invocation • Message constraints <service name="pkg.RecordingService" priority=“78"> <intent-filter count="2" role=“publisher"> <action name="msghandler"/> </intent-filter> </service> <service name="pkg.ProcessingService" priority=“79"> <intent-filter count="2" role=“subscriber"> <action name="msghandler"/> </intent-filter> </service>

  34. Memory Guarantees in RTDroid • Region-based memory management with constant cost for object allocation and reclamation. • Based on the concept of the scoped memory in RTSJ • The complexity of region management is hiddeninour program model • The lifetime management of scope is associated with the lifetime of each application component. http://rtdroid.cse.buffalo.edu

  35. Memory Guarantees in RTDroid Temporary objects for the execution of callback functions Release scope Persistent scope Objects that have the same lifetime as its associated component Immortal scope Objects that have the same lifetime as the application http://rtdroid.cse.buffalo.edu

  36. Region-Based Memory Management in Cochlear Implant Heap Memory (FijiVM) Heap Memory (ART/Dalvik) UI Activities Android Adaptor Processing Service Output Receiver RTDroid Proxy Release Release Persistent Persistent Real-time Runtime in RTDroid Android Runtime Immortal Scope RT Channels

  37. A Fully DynamicSystem http://rtdroid.cse.buffalo.edu

  38. DynamicReal-Time Systems • Ability to install / remove / restart applications • Non real-time • Real-time • JIT as a service … for validation? • Validation of system wide constraints • Modification of an existing application • Adding / removing capabilities http://rtdroid.cse.buffalo.edu

  39. System wide memory management • Can we manage memory more efficiently / predictably if we take a whole system view? • Hussein et al. showed for non RT http://rtdroid.cse.buffalo.edu

  40. Validating Interactions • Session Types • Mechanisms for validating interactions • Communication protocols “match” • Participants are duals of one another • No notion of rate / resources • Partial failures • Error handling without restarting a session http://rtdroid.cse.buffalo.edu

  41. Reasoning about power? • Power management is incredibly important for mobile • We currently do not do anything interesting • Lots of interesting work to explore • Energy types • Power modeling + power management http://rtdroid.cse.buffalo.edu

  42. Validating Timeliness? • What is feasible to validate at runtime? • Can package static results with the app • Bytecodebased WCET (Bates et al.) • Potential starting point? • JIT based specialization / validation? • Online Schedulability analysis? http://rtdroid.cse.buffalo.edu

  43. Evaluation http://rtdroid.cse.buffalo.edu

  44. RTEMS Platform Categories • Soft Real-time • Smartphone • Soft Real-time Desktop • SoftReal-time Embedded http://rtdroid.cse.buffalo.edu

  45. Cochlear Implant Sensing … Processing Real-Time Processing Non-Real-Time UI http://rtdroid.cse.buffalo.edu

  46. Cochlear Implant http://rtdroid.cse.buffalo.edu

  47. Evaluation on jPapabench http://rtdroid.cse.buffalo.edu

  48. jPapaBench (UAV flight control) http://rtdroid.cse.buffalo.edu

  49. Wind Farm Blade Monitoring http://rtdroid.cse.buffalo.edu

  50. Wind Farm Blade Monitoring http://rtdroid.cse.buffalo.edu

More Related