Critiques Ø 1/2 page critiques of research papers Ø Due at 10am on the class day (hard deadline) Ø Email Dingwen dingwenli@wustl.edu in plain txt Ø Back-of-envelop notes - NOT whole essays Ø Guidelines: http://www.cs.wustl.edu/~lu/cse521s/critique.html Ø Critique #3 Ø D ue on 10/31 Ø C. Wang, C. Gill and C. Lu, FRAME: Fault Tolerant and Real-Time Messaging for Edge Computing, IEEE International Conference on Distributed Computing Systems (ICDCS'19), July 2019. 1
Real-Time Systems 101 Chenyang Lu
Consequence of Deadline Miss Ø Hard deadline q System fails if missed. q Goal: guarantee no deadline miss. Ø Soft deadline q User may notice, but system does not fail. q Goal: meet most deadlines most of the time. 3
Cyber-Physical Systems (CPS) Cyber-Physical Boundary Real-Time Hybrid Simulation (RTHS) Ø Since the application interacts with the physical world, its computation must be completed under a time constraint. Ø CPS are built from, and depend upon, the seamless integration of computational algorithms and physical components. [NSF] ^ Robert L. and Terry L. Bowen Large Scale Structures Laboratory at Purdue University 4
Cyber-Physical Systems (CPS) Cyber-Physical Boundary 5
Interactive Cloud Services (ICS) Need to respond within100ms for users to find responsive*. Query doc Doc. index search 2 nd phase ranking Snippet generator Response Search the web * Jeff Dean et al. (Google) "The tail at scale." Communications of the ACM 56.2 (2013) 6
Interactive Cloud Services (ICS) Need to respond within100ms for users to find responsive*. E.g., web search, online gaming, stock trading etc. Search the web * Jeff Dean et al. (Google) "The tail at scale." Communications of the ACM 56.2 (2013) 7
Comparison Ø General-purpose systems q Fairness to all tasks (no starvation) q Optimize throughput q Optimize average performance Ø Real-time systems q Meet all deadlines. q Fairness or throughput is not important q Hard real-time: worry about worst case performance 8
Terminology Ø Task q Map to a process or thread q May be released multiple times Ø Job: an instance of a task Ø Periodic task q Ideal: inter-arrival time = period q General: inter-arrival time >= period Ø Aperiodic task q Inter-arrival time does not have a lower bound 9
Timing Parameters Ø Task T i q Period P i q Worst-case execution time C i q Relative deadline D i Ø Job J ik q Release time: time when a job is ready q Response time R i = finish time – release time q Absolute deadline = release time + D i Ø A job misses its deadline if q Response time R i > D i q Finish time > absolute deadline 10
Example Ø P 1 = D 1 = 5, C 1 = 2; P 2 = D 2 = 7, C 2 = 4. 11
Metrics Ø A task set is schedulable if all jobs meet their deadlines. Ø Optimal scheduling algorithm q A task set is unschedulable under the optimal algorithm à unschedulable under any other algorithms. Ø Overhead: Time required for scheduling. 12
Optimal Scheduling Algorithms Ø Rate Monotonic (RM) q Higher rate (1/period) à Higher priority q Optimal preemptive static priority scheduling algorithm Ø Earliest Deadline First (EDF) q Earlier absolute deadline à Higher priority q Optimal preemptive dynamic priority scheduling algorithm 13
Example Ø P 1 = D 1 = 5, C 1 = 2; P 2 = D 2 = 7, C 2 = 4. 14
Process States Ø A process can be in one of three states: q executing on the CPU; q ready to run; q waiting for data. executing gets CPU preempted needs data gets data Scheduler ready waiting 15
Priority Scheduling Ø Every process has a priority. Ø CPU goes to the ready process with the highest priority. q Fixed vs. dynamic priority q Preemptive vs. non-preemptive 16
Preemptive Priority Scheduling Ø Each process has a fixed priority (1 highest); Ø P 1 : priority 1; P 2 : priority 2; P 3 : priority 3. P 3 released P 1 released P 2 released P2 P1 P2 P3 30 60 0 10 20 40 50 time 17
Preemptive Priority Scheduling Ø Most common real-time scheduling approach q Real-time POSIX q Real-time priorities in Linux q Most RTOS Ø Not the only possible way q Non-preemptive q Clock-driven scheduling q Reservation-based scheduling 18
How Real-Time Is Linux? Ø I believe that Linux is ready to handle applications requiring sub- millisecond process-scheduling and interrupt latencies with 99.99+ percent probabilities of success. No, that does not cover every imaginable real-time application, but it does cover a very large and important subset. Ø The Linux 2.6 kernel, if configured carefully and run on fast hardware, can provide sub-millisecond interrupt and process scheduling latencies with extremely high probabilities of success. There are patches out there that are expected to provide latencies in the tens of microseconds. These patches need some work, but are maturing quickly. Paul McKenney, IBM Linux Technology Center Shrinking slices: Looking at real time for Linux, PowerPC, and Cell 19
Linux Scheduling Ø Real-time scheduling class q Fixed priority • SCHED_FIFO: First-In-First-Out for threads of the same priority • SCHED_RR: Round-Robin for threads of the same priority q SCHED_DEADLINE: EDF Ø Non-real-time scheduling class (SCHED_NORMAL) q CFS: Completed Fair Scheduler Ø Default q Real-time: 0 – 99 q Non-real-time: 100 – 139 20
Scheduler Setup – Priorities Ø chrt command (can also check task priorities) http://www.cyberciti.biz/faq/howto-set-real-time-scheduling-priority-process/ q sudo chrt –f –p 99 4800 # pid 4800 with priority 99 and fifo Ø sched_scheduler [http://linux.die.net/man/2/sched_setscheduler] #include <sched.h> int main() { … struct sched_param sched; sched.sched_priority = 98; if (sched_setscheduler(getpid(), SCHED_FIFO, &sched) < 0) { exit(EXIT_FAILURE); } … } 21
Real-Time Edge Computing Chenyang Lu
Industrial Internet of Things (IIoT) Ø Synergizing sensing, analytics, and control ü Cloud computing for high capacity ü Edge computing for timely performance Cloud Condition monitoring, Emergency response, Machine learning Predictive maintenance, Database ... training … Private cloud for training and storage ... Edge 1 Edge 2 Edge N IIoT Applications services ... ... ... Wireless sensor network (e.g., in a wind farm) 23
Research challenge #1: timeliness Ø Timing constraints: q IIoT applications have latency requirements q Events carrying physical data have temporal semantics Application example: condition monitoring Image source: https://www.maintwiz.com/what-is-condition-monitoring/ 24
Research challenge #1: timeliness Ø Timing constraints: q IIoT applications have latency requirements q Events carrying physical data have temporal semantics Contribution #1 : Cyber-Physical Event Processing Architecture • latency differentiation • time consistency enforcement Application example: condition monitoring Image source: https://www.maintwiz.com/what-is-condition-monitoring/ 25
Research challenge #2: loss-tolerance Ø An IIoT service must deliver messages reliably, but q fault-tolerant systems can be slow or costly q heterogeneous traffic and platforms can increase pessimism cloud Primary service applications IIoT devices edge applications Backup service 26
Research challenge #2: loss-tolerance Ø An IIoT service must deliver messages reliably, but q fault-tolerant systems can be slow or costly q heterogeneous traffic and platforms can increase pessimism Contribution #2 : Fault-Tolerant Real-Time Messaging Architecture cloud Primary service co-scheduling fault-tolerant real-time activities • applications IIoT devices traffic/platform-aware service configuration • edge applications Backup service 27
Research challenge #3: efficiency Ø Efficiency atop loss-tolerance and timeliness: q costly to backup many in-band small computations q costly to recompute for fault recovery Example of in-band computations: AWS Lambda function for IIoT inference Image source: https://aws.amazon.com/lambda/ 28
Research challenge #3: efficiency Ø Efficiency atop loss-tolerance and timeliness: q costly to backup many in-band small computations q costly to recompute for fault recovery Contribution #3 : Adaptive Real-Time Reliable Edge Computing selective lazy data replication • proactive cleanup of obsolete data • Example of in-band computations: AWS Lambda function for IIoT inference Image source: https://aws.amazon.com/lambda/ 29
Contributions Ø Three new IIoT middleware design and implementations: q Real-time cyber-physical event processing (CPEP) q Fault-tolerant real-time messaging (FRAME) q Adaptive real-time reliable edge computing (ARREC) efficiency efficiency efficiency efficiency All have been implemented and validated within the TAO real-time event service [1] . Supplier Proxies CPEP ARREC Subscription & Filtering Event Correlation Dispatching Consumer Proxies loss-tolerance loss-tolerance loss-tolerance loss-tolerance s s s s s s s s e e e e n n n n original TAO i i i i l l l l e e e e m m m m i i i i t t t t FRAME [1] Harrison, T.H., Levine, D.L. and Schmidt, D.C., 1997. The design and performance of a real-time 30 CORBA event service. ACM SIGPLAN Notices , 32 (10), pp.184-200.
Recommend
More recommend
