TDDD07 ht2 2014, Real-time Systems, Linköpings universitet Theory Exercises, 2014 Selected solutions for TDDD07 Real-time Systems Distributed systems, QoS, Real-time communication Massimiliano Raciti Jordi Cucurull Simin Nadjm-Tehrani Real-Time Systems Laboratory Department of Computer and Information Science Linköping University, Sweden December 2014 Copyright © 2014 Simin Nadjm-Tehrani TDDD07 ht2 2014, Real-time Systems, Linköpings universitet Theory Exercises, 2014 Suggested Solutions Q4.1: (a) See course literature. (b) We have the following parameters Node 1 2 3 Period Ti (ms) 5 7 10 Priority (π) 3 2 1 The formulas required to calculate the worst-case response time of each message are the following wn J i j bit n1 C j where wi0 ( q ) Bi qCi wi (q) Bi qCi T j j hp(i ) Ri (q) Ji wi (q) qTi Ci Ri max (Ri (q)) q0..Qi 1 In addition, before using them, the number of possible messages, Qi, that become ready before the end of the busy period must be calculated with the following formulas: t n J i j C j t Bi T j j hep(i ) t J Qi i i Ti n1 i where ti0 Ci The maximum blocking time for respective messages is B1 B2 135s and B3 0 s . Frames sent by n3 have the lowest priority, reason why their blocking factor is defined to zero. The transmission time is given by C i 135 bit 135s . In this first case we assume J i 0 s , i=1..3. Response time R3: We calculate first the length of the busy period for message 3: t 30 C 3 135s t 30 J 1 t 30 J 2 t 30 J 3 t B3 C1 C 2 C3 405s T1 T2 T3 t1 J1 t 31 J 2 t 31 J 3 t 32 B3 3 C C 1 2 C3 405s T1 T2 T3 1 3 t 32 t 31 t 3 405s TDDD07 ht2 2014, Real-time Systems, Linköpings universitet Theory Exercises, 2014 Then the number of instances Q3 that become ready: t J 3 Q3 3 1 T 3 The response time must be calculated for each of the Q3 instances: w30 (0) B3 0C 3 0 s w30 J 1 bit w30 J 2 bit w (0) B3 0C 3 C1 C 2 270 s T1 T2 1 1 w J 1 bit w3 J 2 bit w32 (0) B3 0C 3 3 C1 C 2 270 s T1 T2 1 3 w32 w31 w3 270s R3 (0) J 3 w3 (0) 0T3 C 3 405s R3 max (Ri (q)) R3 (0) 405 s (c) q0..Q3 1 Response time R3 with Jitter: J1 J2 5ms, J3 8ms t 30 C 3 135s t 0 J t 0 J t 0 J t13 B3 3 1 C1 3 2 C2 3 3 C3 540 s T1 T2 T3 1 1 t 3 J1 t 3 J2 t13 J3 2 t 3 B3 C1 C2 C3 540 s T1 T2 T3 t 32 t13 t 3 540 s Then the number of instances Q3 that become ready: t J 3 Q3 3 1 T3 The response time must be calculated for each of the Q3 instances: w30 (0) B3 0C 3 0 s w0 J w0 J w13 (0) B3 0C3 3 1 bit C1 3 2 bit C2 405 s T1 T2 1 1 w J w J w32 (0) B3 0C3 3 1 bit C1 3 2 bit C2 405 s T1 T2 w32 w13 w3 405 s R3 (0) J3 w3 (0) 0T3 C3 8540 s R3 max (Ri (q)) R3 (0) 8540 s q0..Q3 1 TDDD07 ht2 2014, Real-time Systems, Linköpings universitet Theory Exercises, 2014 Q4.2: Message m1 m2 m3 Period Ti (ms) 20 10 5 Priority (π) high middle low Jitter (ms) 1 2 0 Response time R3: B3 0ms, since m3 is the lowest priority process. First the length of the busy period for message 3 is calculated: t 30 C3 1ms t 0 J t 0 J2 t 30 J3 t13 B3 3 1 C1 3 C C3 3ms 2 T2 T1 T3 t1 J t1 J t1 J t13 B3 3 1 C1 3 2 C2 3 3 C3 3ms T1 T3 T2 t 3 3ms Then the number of instances Q3 of message 3 that become ready before the end of the busy period: t J Q3 3 3 1 T3 The response time must be calculated for each of the Q3 instances, in this case just one. w30 (0) B3 0C3 0ms w30 J1 bit w30 J2 bit 1 w3 (0) B3 0C3 C1 C2 2ms T1 T2 1 1 w J w J w32 (0) B3 0C3 3 1 bit C1 3 2 bit C2 2ms T1 T2 w3 (0) 2ms R3 (0) J3 w3 (0) 0T3 C3 3ms R3 max (Ri (q)) R3 (0) 3ms q0..Q3 1 Response time R2: B2 1ms t 20 C2 1ms t 20 J1 t 20 J2 1 t 2 B2 C1 C2 3ms T1 T2 TDDD07 ht2 2014, Real-time Systems, Linköpings universitet Theory Exercises, 2014 t 20 J1 t 20 J2 t B2 C1 C2 3ms T1 T2 2 2 t 2 3ms Then the number of instances Q2 that become ready: t J 2 Q2 2 1 T2 The response time must be calculated for each of the Q2 instances: w20 (0) B2 0C2 1ms w0 J w12 (0) B2 0C2 2 1 bit C1 2ms T1 w1 J w22 (0) B2 0C2 2 1 bit C1 2ms T1 R2 (0) J2 w2 (0) 0T2 C2 5ms R2 max (Ri (q)) R2 (0) 5ms q0..Q2 1 Response time R1: B1 1ms t10 C2 1ms t 0 J t11 B1 1 1 C1 2ms T1 t11 J1 2 t1 B1 C1 2ms T1 t1 2ms Then the number of instances Q1 that become ready: t J Q1 1 1 1 T1 The response time must be calculated for each of the Q1 instances: w1 (0) B1 0C1 1ms R1 (0) J1 w1 (0) 0T1 C1 3ms TDDD07 ht2 2014, Real-time Systems, Linköpings universitet Theory Exercises, 2014 Q4.3: Message m1 (high priority) m2 (middle priority) m3 (low priority) period (ms) 30 15 5 Jitter 5 0 0 In this case only the response time for the lowest priority message is required, i.e. m3. bit is considered to be smaller than 1ms Response time R3: B3 0ms, since m3 is the lowest priority process. First the length of the busy period for message 1 is calculated: t30 C3 1ms t0 J t0 J t0 J 1 5 1 0 1 0 1 1 1 3ms t31 B3 3 1 C1 3 2 C2 3 3 C3 0 30 15 5 T1 T2 T3 t31 J1 t31 J2 t31 J3 4 5 4 0 4 5 1 t3 B3 1 1 1 3ms C3 0 C1 C2 30 15 5 T1 T2 T3 t3 t32 t31 3ms Then the number of instances Q3 of message 3 that become ready before the end of the busy period: t J 3 0 Q3 3 3 1 T3 5 The response time must be calculated for each of the Q3 instances, in this case just one. w30 (0) B3 0C3 0ms w0 J w0 J 0 5 bit 0 0 bit w31 (0) B3 0C3 3 1 bit C1 3 2 bit C2 0 0 1 1 2ms 30 T1 T2 15 w1 J w1 J 2 5 bit 2 0 bit w32 (0) B3 0C3 3 1 bit C1 3 2 bit C2 0 0 1 1 2ms 30 T1 T2 15 w32 (0) w31 (0) 2ms w3 (0) 2ms R3 (0) J 3 w3 (0) 0T3 C3 0 2 0 1 3ms R3 max (Ri (q)) R3 (0) 3ms q0..Q3 1 Q4.4: a) The priorities for messages in a CAN network must be the same fixed priorities used in the priority-based scheduling of the processes in the nodes that are connected to the bus. TDDD07 ht2 2014, Real-time Systems, Linköpings universitet Theory Exercises, 2014 False. The CAN network is completely independent of the processes that run in each node that it is connected to the bus, therefore the priorities can be different b) If one node that is connected to a TTP bus crashes, this can be detected easier by the other nodes than if the system would use a CAN bus. True. TTP /C has a membership service that is in charge of monitoring the “health” of the nodes, excluding them in case of failure. c) If a process exceeds its assumed worst case execution time (WCET) at some point in time, it is stopped from sending its final output on a TTP buss. True. If the process exceeds the WCET and misses its assigned slot to transmit, it cannot send the final output at that time. d) On a CAN bus a high priority message can only be delayed (blocked) once by messages of lower priority. True. A high priority message can only be delayed by a lower priority messages that is already being transmitted, since no preemption exists in the CAN bus. Q5.1: a) Logic clock Vector clock TDDD07 ht2 2014, Real-time Systems, Linköpings universitet Theory Exercises, 2014 b) (a,e) and (c,f) are concurrent event. Let VC(a) and VC(e) be the vector timestamps at the time when a or e occurs. The events a and e are concurrent since none of VC(a) VC(e) or VC(e) VC(a) Q5.2: P Q R b2 a1 e1 c2 g3 f2 d3 h4 In order to check whether there are events x and y in which LC(x) < LC(y) but is not the case that x happen before y, we should determine all the “happens before relationships”. ab (because from the point of view of P, a occurs before than b) ac (because c is the event of reception of a message m and a is the event of sending m) ec , ef, bd, cg, gh, fd, dh. Using the transitive property (xy and yz -> xz), we get all the possible relationships: ab, ac, ad, ah, bd, bh, cg, ch, dh, ec, eg, eh, ef, ed fd, fh, gh. Now, if we take the events b and g, we can see that LC(b)<LC(g), but we don’t have bg. B and g were two “easy” examples, since graphically you can recognise that they are concurrent. There are other cases anyway that are not so easy to recognise: c and d, for example. LC(c)<LC(d) but we don’t have cd. Q5.3: An example of distributed real time system with hard deadlines can be the control system of car, where many elements are distributed and linked with a bus. This system has hard deadlines because the safety of the user depends on the correctly functionality of the service, i.e. no deadline misses are allowed. An example of distributed real time system with soft deadlines can be a regular videoconference system, such as Skype. The system has soft deadlines because in case some of them are missed it will just affect the video/sound quality of the call. TDDD07 ht2 2014, Real-time Systems, Linköpings universitet Theory Exercises, 2014 Q5.4: This is the scenario described: a cab b cad cac c d Node a has an associated clock ca with time t. We represent the time calculated after synchronisation as ca ' . This new time is calculated as: ca ' ca cab cac cad 4 where cab cac cad are the clocks the other nodes (b, c, and d) send to a. In this scenario two of the nodes (b and c) will send a time that differ exactly δ from t. The other node (d) will send a time that differs γ from t and γ < δ. Given this information, three cases can be distinguished: 1) ca t cab t new time is ca ' cac t cad t t t t t 1 t 4 4 then ca ca ' and synchronisation is met in this case. 2) ca t cab t new time is ca ' cac t cad t 1 1 t t t t t 4 2 4 then ca ca ' and synchronisation is met in this case. 3) ca t cab t cac t cad t TDDD07 ht2 2014, Real-time Systems, Linköpings universitet Theory Exercises, 2014 new time is ca ' 1 1 t t t t t 4 2 4 then ca ca ' and synchronisation is met in this case. Then the synchronisation requirement in node A is met. b) S C1 [0,0,0] [1,0,1] [0,0,0] [2,0,1] c [3,1,1] [4,1,1] a [0,1,0] b [0,0,0] [0,0,1] C2 [4,2,1] d [2,0,2] Concurrent events a: C1-Sending [0,1,0] b: C2-Sending [0,0,1] VC (a) VC (b) and VC (b) VC (a) c: Reception C1 request [3,1,1] d: Reception S response in C2 [2,0,2] VC (c) VC (d ) and VC (d ) VC (c) Q5.5 Consider the following two terms used in quality of service (QoS) requirements descriptions, and identify for each term whether it is an application level description or an enforcement level indication: loss ratio, video quality. TDDD07 ht2 2014, Real-time Systems, Linköpings universitet Theory Exercises, 2014 Loss ratio is an enforcement level indication, since it is a generic quality of service parameter applicable to any underlying service to support applications. Video quality, instead, is an application level description since it refers to a quality of service parameter specific of a video application that it is directly noticeable by the user.