3.1 MB - Evernote

More documents

Recommendations

Info

4.4 End of Simulation Parallel Transaction-oriented Simulation In transaction-oriented simulation a simulation is complete when the defined end state is reached, i.e. the termination counter reaches a value less or equal to zero. When using an optimistic synchronisation algorithm for the parallelisation of transaction-oriented simulation it is crucial to consider that optimistic algorithms will first execute all local events without guarantee that the causal order is correct. They will recover from wrong states by performing a rollback if it later turns out that the causal order was violated. Therefore any local state reached by an optimistic LP has to be considered provisional until a GVT has been received that guarantees the state. In addition it needs to be considered that at any point in real time it is most likely that each of the LPs has reached a different local simulation time so that after an end state has been reached by one of the LPs that is guaranteed by a GVT it is important to synchronise the states of all LPs so that the combined end state from all model partitions is equivalent to the model end state that would have been reached in a sequential simulator. To summarise, a parallel transaction-oriented simulation based on an optimistic algorithm is only complete when the defined end state has been reached in one of the LPs and when this state has been confirmed by a GVT. Furthermore if the confirmed end of the simulation has been reached by one of the LPs then the states of all the other LPs need to be synchronised so that they all reflect the state that would exist within the model when the Transaction causing the simulation end executed its TERMINATE block. These significant aspects regarding the simulation end of a parallel transaction- oriented simulation that had not been considered in [19]. A mechanism is suggested for this work that leads to a consistent and correct global end state of the simulation considering the problems mentioned above. For this mechanism the LP reaching a provisional end state is switched into the provisional end mode. In this mode the LP will stop to process any further Transactions leaving the local model partition in the same state but it will still respond to and process control messages like GVT parameter requests and it will receive Transactions from other LPs that might cause a rollback. The LP will stay in this provisional end mode until the end of the simulation is confirmed by a GVT or a received Transaction causes a rollback with a potential re-execution that is not resulting in the same end state. While the LP is in the provisional end mode additional GVT parameters are passed on for every GVT 35
36 Parallel Transaction-oriented Simulation calculation denoting the fact that a provisional end state has been reached and the simulation time and priority of the Transaction that caused the provisional end. The GVT calculation process can then assess whether the earliest current provisional end state is guaranteed by the GVT. If this is the case then all other LPs are forced to synchronise to the correct end state by rolling back using the simulation time and priority of the Transaction that caused the provisional end and the simulation is stopped. 4.5 Cancellation Techniques Transaction-oriented simulation has some specific properties compared to discrete event simulation. One of these properties is that Transactions do not consume simulation time while they are moving from block to block. This has an influence on which of the synchronisation algorithms are suitable for transaction-oriented simulation as described in 4.1 but also on the cancellation techniques used. If a Transaction moves from LP1 to LP2 then it will arrive at LP2 with the same simulation time that it had at LP1. A Transaction moving from one LP to another is therefore equivalent to an event in discrete event simulation that when executed creates another event for the other LP with exactly the same time stamp. Because simulation models can contain loops as it is common for the models of quality control systems where an item failing the quality control needs to loop back through the production process (see [26] for an example) this specific behaviour of transaction-oriented simulation can lead to endless rollback loops if aggressive cancellation is used (cancellation techniques were briefly described in 2.5.2). The example in Figure 10 demonstrates this effect. It shows the movement of a Transaction x1 from LP1 to LP2 but without a delay in simulation time the Transaction is transferred back to LP1. As a result LP1 will be rolled back to the simulation time just before x1 was moved. At this point two copies of Transaction x1 will exist in LP1. The first one is x1 itself which needs to be moved again and the second is x1’ which is the copy that was send back from LP2. This is the point from where the execution differs between lazy cancellation and aggressive cancellation. In lazy cancellation x1 would be moved again resulting in the same transfer to LP2. But because x1 was sent to LP1 already it will not be transferred again and no anti-transaction will be sent. From here
Page 1 and 2: TRANSACTION-ORIENTED SIMULATION IN
Page 3 and 4: Table of Content II Table of Conten
Page 5 and 6: IV Table of Content 6 VALIDATION OF
Page 7 and 8: Figures VI Figures Figure 1: Ad Hoc
Page 9 and 10: Tables VIII Tables Table 1: Change
Page 11 and 12: 2 Introduction synchronisation algo
Page 13 and 14: 2 Fundamental Concepts Fundamental
Page 15 and 16: Figure 1: Ad Hoc Grid architecture
Page 17 and 18: 8 Fundamental Concepts In continuou
Page 19 and 20: 10 Fundamental Concepts Two other a
Page 21 and 22: 12 Fundamental Concepts known as st
Page 23 and 24: 14 Fundamental Concepts event execu
Page 25 and 26: 3 Ad Hoc Grid Aspects 16 Ad Hoc Gri
Page 27 and 28: 18 Ad Hoc Grid Aspects resources an
Page 29 and 30: 20 Ad Hoc Grid Aspects means that a
Page 31 and 32: Parallel Transaction-oriented Simul
Page 33 and 34: 24 Parallel Transaction-oriented Si
Page 35 and 36: 4.2 Synchronisation algorithm 26 Pa
Page 43: 34 Parallel Transaction-oriented Si
Page 49 and 50: 5 Implementation 40 Implementation
Page 51 and 52: 42 Implementation confirm a provisi
Page 53 and 54: 44 Implementation large numerical p
Page 55 and 56: 46 Implementation A detailed descri
Page 57 and 58: 48 Implementation But in a parallel
Page 59 and 60: 50 Implementation GPSS test models
Page 61 and 62: Simulation Controller side 52 Imple
Page 63 and 64: 54 Implementation technique describ
Page 65 and 66: Implementation Euclidean distance b
Page 67 and 68: 58 Implementation chain at the corr
Page 69 and 70: 60 Implementation The algorithm wil
Page 71 and 72: No Start Is Active Object body acti
Page 73 and 74: 5.3.2 GVT Calculation and End of Si
Page 75 and 76: 66 Implementation provisional simul
Page 77 and 78: Implementation relatively basic per
Page 79 and 80: 70 Implementation log4j.logger.para
Page 81 and 82: proactive-log4j 72 Implementation T
Page 83 and 84: 74 Implementation Memory Allocation
Page 85 and 86: 76 Validation of the Parallel Simul
Page 93 and 94: 6.4 Validation 4 84 Validation of t
Page 95 and 96:
86 Validation of the Parallel Simul
Page 97 and 98:
… LpccEnabled=true LpccClusterNum
Page 99 and 100:
Validation 5.2 Validation of the Pa
Page 101 and 102:
Page 103 and 104:
Page 105 and 106:
7 Conclusions 96 Conclusions Even s
Page 107 and 108:
References 98 References [1] Amin K
Page 109 and 110:
[19] Krafft G. Parallelisation of T
Page 111 and 112:
Appendix A: Detailed GPSS Syntax 10
Page 113 and 114:
Reserved word: DEPART Syntax: [] DE
Page 115 and 116:
Reserved word: SEIZE Syntax: [] SEI
Page 117 and 118:
Setting: LpccClusterNumber Default
Page 119 and 120:
Appendix C: Simulator log4j loggers
Page 121 and 122:
Logger: parallelJavaGpssSimulator.l
Page 123 and 124:
114 Appendix D: Structure of the at
Page 125 and 126:
Appendix E: Documentation of select
Page 127 and 128:
Page 129 and 130:
Page 131 and 132:
!"#"$$%$&"'"(!))*+,-$"./#0$! 1$"))
Page 133 and 134:
Page 135 and 136:
!/+/.7/8$ Appendix E: Documentation
Page 137 and 138:
Returns: Appendix E: Documentation
Page 139 and 140:
!"#$%&''$()*)")$ +',)$-)$. #,/. !"#
Page 141 and 142:
!"#$%&'()#%*+,"-*.# Appendix E: Doc
Page 143 and 144:
Page 145 and 146:
Page 147 and 148:
Page 149 and 150:
Page 151 and 152:
Page 153 and 154:
Constructor Detail !"#$%&'$(#$)*$%+
Page 155 and 156:
Page 157 and 158:
Validation 1.1, output of simulate:
Page 159 and 160:
Validation 2, output of LP: Appendi
Page 161 and 162:
Appendix F: Validation output logs
Page 163 and 164:
Validation 2, output of simulate: A
Page 165 and 166:
Validation 3.1, output of LP1: Appe
Page 167 and 168:
Page 169 and 170:
Page 171 and 172:
Page 173 and 174:
Validation 4, output of LP1: Append
Page 175 and 176:
Page 177 and 178:
Page 179 and 180:
simulation for time 2000) (628) 20:
Page 181 and 182:
Page 183 and 184:
Page 185 and 186:
Page 187 and 188:
Validation 4, output of simulate: A
Page 189 and 190:
Page 191 and 192:
Page 193 and 194:
Page 195 and 196:
(135) 19:37:56,477 Total transactio
Page 197 and 198:
Page 199 and 200:
Page 201 and 202:
Page 203 and 204:
Page 205 and 206:
Page 207 and 208:
(68) 19:37:56,619 by the transactio
Page 209 and 210:
Page 211 and 212:
Page 213 and 214:
Page 215 and 216:
Page 217 and 218:
Page 219 and 220:
Page 221 and 222:
Page 223 and 224:
Page 225 and 226:
Page 227 and 228:
(1295) 14:25:22,740 Simulation stop
Page 229 and 230:
Page 231 and 232:
Page 233 and 234:
Page 235 and 236:
Page 237 and 238:
(68) 14:25:22,888 by the transactio
Page 239 and 240:
Validation 6.2, output of LP2: (1)
Page 241:
(32) (1,2) 0 765 Block: TRANSFER 0.
show all

3.1 MB - Evernote

Create successful ePaper yourself

Delete template?

Save as template?