Selected solutions for TDDD07 Real-time Systems

advertisement
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
n1
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))
q0..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 
n1
i
where
ti0  Ci
The maximum blocking time for respective messages is B1  B2  135s 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  135s .
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  135s
 t 30  J 1 
 t 30  J 2 
 t 30  J 3 
t  B3  
C1  
C 2  
C3  405s
 T1 
 T2 
 T3 
t1  J1 
 t 31  J 2 
 t 31  J 3 
t 32  B3   3
C

C

 1 
 2 
C3  405s
 T1 
 T2 
 T3 
1
3
t 32  t 31  t 3  405s
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  270s
R3 (0)  J 3  w3 (0)  0T3  C 3  405s
R3  max (Ri (q))  R3 (0)  405 s
(c)
q0..Q3 1
Response time R3 with Jitter:
J1  J2  5ms, J3  8ms
t 30  C 3  135s
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
q0..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
q0..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
q0..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
q0..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”.
ab (because from the point of view of P, a occurs before than b)
ac (because c is the event of reception of a message m and a is the event of sending m)
ec , ef, bd, cg, gh, fd, dh.
Using the transitive property (xy and yz -> xz), we get all the possible
relationships:
ab, ac, ad, ah, bd, bh, cg, ch, dh, ec, eg, eh, ef, ed fd, fh, gh.
Now, if we take the events b and g, we can see that LC(b)<LC(g), but we don’t have bg.
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 cd.
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.
Download