Critiques 1/2 page critiques of research papers Due at 10am on the - - PowerPoint PPT Presentation
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:
Ø 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
Ø Due 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
q System fails if missed. q Goal: guarantee no deadline miss.
q User may notice, but system does not fail. q Goal: meet most deadlines most of the time.
3
4
Cyber-Physical Boundary
^ Robert L. and Terry L. Bowen Large Scale Structures Laboratory at Purdue University
Real-Time Hybrid Simulation (RTHS)
5
Cyber-Physical Boundary
6
Search the web
* Jeff Dean et al. (Google) "The tail at scale." Communications of the ACM 56.2 (2013)
2nd phase ranking Snippet generator doc
Response Query
7
* Jeff Dean et al. (Google) "The tail at scale." Communications of the ACM 56.2 (2013)
Search the web
q Fairness to all tasks (no starvation) q Optimize throughput q Optimize average performance
q Meet all deadlines. q Fairness or throughput is not important q Hard real-time: worry about worst case performance
8
q Map to a process or thread q May be released multiple times
q Ideal: inter-arrival time = period q General: inter-arrival time >= period
q Inter-arrival time does not have a lower bound 9
q Period Pi q Worst-case execution time Ci q Relative deadline Di
q Release time: time when a job is ready q Response time Ri = finish time – release time q Absolute deadline = release time + Di
q Response time Ri > Di q Finish time > absolute deadline 10
Ø P1 = D1 = 5, C1 = 2; P2 = D2 = 7, C2 = 4.
11
q A task set is unschedulable under the optimal algorithm à
unschedulable under any other algorithms.
12
q Higher rate (1/period) à Higher priority q Optimal preemptive static priority scheduling algorithm
q Earlier absolute deadline à Higher priority q Optimal preemptive dynamic priority scheduling algorithm 13
Ø P1 = D1 = 5, C1 = 2; P2 = D2 = 7, C2 = 4.
14
q executing on the CPU; q ready to run; q waiting for data.
15
executing ready waiting needs data gets data preempted gets CPU Scheduler
q Fixed vs. dynamic priority q Preemptive vs. non-preemptive
16
17
time P2 released P1 released P3 released 30 10 20 60 40 50 P2 P2 P1 P3
q Real-time POSIX q Real-time priorities in Linux q Most RTOS
q Non-preemptive q Clock-driven scheduling q Reservation-based scheduling
18
Ø 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
q Fixed priority
q SCHED_DEADLINE: EDF
q CFS: Completed Fair Scheduler
q Real-time: 0 – 99 q Non-real-time: 100 – 139 20
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
21
#include <sched.h> int main() { … struct sched_param sched; sched.sched_priority = 98; if (sched_setscheduler(getpid(), SCHED_FIFO, &sched) < 0) { exit(EXIT_FAILURE); } … }
ü Cloud computing for high capacity ü Edge computing for timely performance
23
Wireless sensor network (e.g., in a wind farm) Private cloud for training and storage Machine learning training
...
...
Applications
...
IIoT services Edge 1
Database
...
Edge 2 Edge N
...
Cloud
Condition monitoring, Emergency response, Predictive maintenance, …
q IIoT applications have latency requirements q Events carrying physical data have temporal semantics
24
Image source: https://www.maintwiz.com/what-is-condition-monitoring/
Application example: condition monitoring
q IIoT applications have latency requirements q Events carrying physical data have temporal semantics
25
Image source: https://www.maintwiz.com/what-is-condition-monitoring/
Application example: condition monitoring
q fault-tolerant systems can be slow or costly q heterogeneous traffic and platforms can increase pessimism
26 Primary service Backup service edge applications IIoT devices cloud applications
q fault-tolerant systems can be slow or costly q heterogeneous traffic and platforms can increase pessimism
27 Primary service Backup service edge applications IIoT devices cloud applications
q costly to backup many in-band small computations q costly to recompute for fault recovery
28
Image source: https://aws.amazon.com/lambda/
Example of in-band computations: AWS Lambda function for IIoT inference
q costly to backup many in-band small computations q costly to recompute for fault recovery
29
Image source: https://aws.amazon.com/lambda/
Example of in-band computations: AWS Lambda function for IIoT inference
q Real-time cyber-physical event processing (CPEP) q Fault-tolerant real-time messaging (FRAME) q Adaptive real-time reliable edge computing (ARREC) 30
[1] Harrison, T.H., Levine, D.L. and Schmidt, D.C., 1997. The design and performance of a real-time CORBA event service. ACM SIGPLAN Notices, 32(10), pp.184-200.
efficiency t i m e l i n e s s loss-tolerance efficiency t i m e l i n e s s loss-tolerance efficiency t i m e l i n e s s loss-tolerance efficiency t i m e l i n e s s loss-tolerance
CPEP FRAME ARREC
Subscription & Filtering Supplier Proxies Event Correlation Dispatching Consumer Proxies
31
efficiency t i m e l i n e s s loss-tolerance
with CPEP
CPEP
Supplier Proxies Consumer Proxies Subscription & Filtering Supplier Proxies Event Correlation Dispatching Consumer Proxies
q Absolute time consistency
q Relative time consistency
32 Oi: operations (filtering, transformation, encryption, …)
IIoT devices IIoT event service
s1 s2 s3 s5 s4
High priority Middle priority Low priority
c1 c2 c3 c4
Low priority
IIoT applications
q Absolute time consistency q Relative time consistency
33
s1 s2 s3 s5 s4
High priority Middle priority Low priority
c1 c2 c3 c4
Low priority S2 S1 S3 C2 t1 t2 t3 t4 t5 t7 t6
34
Both workers and movers are further prioritized, enabling an appropriate activity ordering.
s1 s2 s3 s5 s4
High priority Middle priority Low priority
c1 c2 c3 c4
Low priority
q Marking: deferring the handling to consumers q Shedding: cancelling all subsequent processing 35
s1 s2 s3 s5 s4 c1 c2 c3 c4
es1 es2 es3
(Improving efficiency)
q One timestamp per event type q Comparing the maximum time difference with validity interval
q Marking: deferring the handling to consumers q Shedding: cancelling all subsequent processing 36
s1 s2 s3 s5 s4 c1 c2 c3 c4
es1 es2 es3 es1
'
(Improving efficiency)
q Filtering q Data transform q Encryption
q Apache Flink streaming processing framework [1]
37
High priority Middle priority Low priority EKF2 FFT1 CAT1 AES2 FFT2 EKF4 FFT3 AES3 EKF1 AES1 c2 c1 c3 s1 s2 s3 s4 s7 s8 50 Hz 200 Hz 100 Hz EKF3 s5 s6
Machine 1 Suppliers Machine 2 CPEP Machine 3 Consumers
[1] https://flink.apache.org
38
99th percentile latency (unit: ms) CPEP maintained high-priority latency performance as workload increased.
High Middle Low
CPEP differentiated latency according to priority level.
#
39
Improve the throughput
Save CPU utilization.
Latency of low-priority processing
40
High priority Middle priority Low priority EKF3 FFT3 CAT2 AES2 FFT4 c2 s5 s6 EKF4 s7 s8 EKF1 FFT1 CAT1 AES1 FFT2 c1 s1 s2 EKF2 s3 s4 CAT3 AES4 c3 AES3 100 Hz 100 Hz
41
Latency of low-priority processing CPU utilization
42
efficiency timeliness loss-tolerance
Subscription & Filtering Supplier Proxies Event Correlation Dispatching Consumer Proxies
FRAME
Supplier Proxies Consumer Proxies
q : the tolerable number of consecutive losses for topic i
43
Image source: https://www.originlab.com/doc/Origin-Help/Math-Inter-Extrapoltate-YfromX
Value of Application examples emergency response; predictive maintenance k > 0 condition monitoring
(Within the tolerable number, applications may use estimates for the missing data.)
1.
2.
44
[1] Budhiraja, N., Marzullo, K., Schneider, F.B. and Toueg, S., 1993. The primary-backup approach. Distributed systems, 2, pp.199-216. Primary service Backup service edge applications IIoT devices cloud applications
q Specify provable deadlines for message replication and dispatch q Co-schedule replication and dispatch using, e.g., the earliest-
45
Primary service Backup service edge applications IIoT devices cloud applications dispatch replication
1.
2.
46
Events between message creation and its delivery:
47 : # of most-recent messages a publisher can retransmit
: loss-tolerance requirement : topic’s sending period: latency requirement
Primary Broker Publisher Subscriber
ΔPB ΔBS
Primary Broker Publisher Backup Broker Subscriber
ΔPB ΔBB
crash
x ( Ni + Li ) Ti
...
48
Data subscriber Data publisher Primary Broker Data publisher Publishers Data subscriber Subscribers ... ... Message Delivery Message Proxy Replicators Dispatchers Message Delivery Replicators Dispatchers Backup Broker Message Proxy
q FRAME+; FRAME; FCFS; FCFS-
49
ES2 ES1 Primary Broker Backup Broker Edge Subscribers Cloud Subscriber EP1 B1 B2 CS1 Edge Publishers EP2
50
Success rate of meeting loss-tolerance requirements
A small increase in Ni can greatly improve performance (FRAME+). FRAME succeeded in assuring loss-tolerance.
51
FRAME can mitigate latency penalty. Without suppressing replication, pruning could overload the system. No pruning, however, could cause latency penalty by re- sending obsolete messages.
when the Primary host crashed
52
Success rate of meeting soft latency requirements
All configurations gave similar latency performance.
53
efficiency timeliness l
s
e r a n c e
Subscription & Filtering Supplier Proxies Event Correlation Dispatching Consumer Proxies
ARREC
with ARREC Supplier Proxies Consumer Proxies
q CPEP: Real-time cyber-physical event processing q FRAME: Fault-tolerant real-time messaging q ARREC: Adaptive real-time reliable edge computing 54
efficiency timeliness l
s
e r a n c e
Wireless sensor network (e.g., in a wind farm) Private cloud for training and storage Machine learning training
...
...
Applications
...
IIoT services Edge 1
Database
...
Edge 2 Edge N
...
Cloud