Outline

1
Outline

• Global Virtual Time Algorithm
• Checkpoint Techniques in Time Warp
• References
• Presented by
• Fazel Keshtkar
• http//www.site.uottawa.ca/akesh081/
• CourseCSI5661
• Prof. Dr. Boukerche
• http//www.site.uottawa.ca/boukerch/

2
Objective

• Global Virtual Time and Distributed
  Synchronization.

3
Table of Contents

• Problems
• Global Virtual Time.
• Reclaiming Memory.
• Determining of progress of simulation.
• Interaction Simulation support.
• Message in Transit Flow Control
• Disrupting Event Processing
• Risk Optimism
• Interaction Simulation
• Scalable Communication
• SPEEDES ALGORITHM
• Performance of SPEEDES Algorithm

4
Problems

• Problems
• Scalability
• Efficiency
• Flow Control
• Interactive Support
• Real Time Use

5
Problems

• Global Virtual Time.
• Fundamental Synchronization Concept in Optimistic
  Simulation.
• Defined as earliest Time Tag (un process events
  in Distributed Simulation)
• Most technique focus on
• specific type of Simulation problem.
• Hardware Support

6
Global Virtual Time

• SPEEDES
• Means the Synchronous Parallel Environment
  for Emulation and Discrete-Event Simulation
• Provide Flow Control
• by risk-free flushing out events
• easily Implement in any Hardware by set of Global
  Reduction operation

7
Global Virtual Time

• Why Distributed Simulation Needs to Update and
  Estimate GVT
• Reclaiming Memory
• Determining Progress of the Simulation
• Interactive Simulation Support

8
Reclaiming Memory

• Optimistic Simulation
• Save State Information (Events) in order to
  Support Rollback.
• State Saving Consume Valuable Memory Resource.
• Events Never Permitted to Schedule other Events
  in Past
• Time TagltGVT always are Safe to Return
  State-Saving Memory.

9
Reclaiming Memory

• How often should Update GVT for Reclaiming Memory
• if Incremental State Saving Technique Used.
• Is Possible for some of Simulation that Run
  without State-Saving Memory.
• When Simulation use State-Saving Mechanism
• GVT must Update frequently
• Using State Skipping Strategy to Reduce Memory
  Consumption
• Protect Memory by Cancelback Protocol.

10
Determining Progress of Simulation

• Often Simulation Complete when GVT reaches End
  Time.
• To Monitor Various Performance Statistics e.g
  Rollbacks, Antimessages,

11
Determining Progress of Simulation

• How often GVT should be Update for Determining
  Progress of Simulation?
• Not Important just for Collecting Statistic.
• Important to Determine GVT when Simulation Has
  Reached its End Time.
• Inefficient Update GVT when Simulation Completed
  Events.
• Good Simulation Mechanism should be able to
  Detect Ended of Simulation.

12
Interactive Simulation Support

• in Distributed-Optimistic Simulation
• Events allowed to Released Information to outside
  world as they are committed.
• Events with Time TagltGVT are Permitted to output
  Information to External World.
• Minimize Time Delay between its Output and Input
  from Outside World.

13
Interactive Simulation Support

• How often Should GVT Be Update for Supporting
  Interactive Simulation?
• GVT should update very Frequently
• Time Difference between Time Tag and GVT will
  reduced.
• Finding Efficient GVT Algorithm.
• If more Frequently update Synchronization
  overhead became Large Factor.

14
Message in Transit and Flow Control

• Who can GVT be Update when message are still in
  Transit?
• Approach
• 1st by Requiring Acknowledgments for Every
  Message sent.
• May hurt the Performance (double message)
• Required Extra work to Manage which Message have
  or Not have Acknowledgment.
• Using special hardware to providing
  Acknowledgment.

15
Message in Transit and Flow Control

• 2nd Acknowledgment only Last Message Received
  by each Node. (like FIFO)
• Reduce number of Message by O(N2).
• Finding Minimum Time Tag
• keep tracking

16
Message in Transit and Flow Control

• 3th Each LP Compute GVT information at its Own
  Rate.
• Problem
• The Scale is Not well when Thousand of Objects
  per Nodes.

17
Message in Transit and Flow Control

• Is it possible to Determine GVT without
  Acknowledgement?
• Flush Out all Message from Network when GVT
  Update is Initiated.
• Message-in-Transit Problem goes away.

18
Message in Transit and Flow Control

• Example If every Events Generate new Message.
• 1- 1ms sec for process
• 2- 5ms to send message
• gtthis Simulation has Flow Control Problem.
• Without Flow control, network became Congest.
• Flow Control is Essential in Distributed
  Simulation.
• SPEEDES GVT Algorithm Provide Flow Control.

19
Disrupting Event Processing

• Some GVT Algorithms run Without Disrupting
• Many GVT Algorithms Initiated Periodically by
  Invoking GVT request among the processing Node.
• Normally When GVT request is made
• Event Processing is Suspend until New GVT value
  Determined
• Inefficient if GVT Update very Frequently

20
Disrupting Event Processing

• Example
• GVT request every 100ms
• 50ms to Compute GVT
• gtBest Case Simulation Efficient is 50
• if GVT Request Every 5 Second
• gtJust 1 reduction in Efficiency
• So GVT should Update as Frequently as Possible

21
Disrupting Event Processing

• SPEEDES Algorithm Process Events while Updating
  GVT
• Event Processing Switches to Risk-Free Mode.
• All other Message in Transit Flushed Out of
  System.
• If Straggler Message Received they will cause
  Antimessage
• gt Flushing-Out is very Involve

22
Disrupting Event Processing

• Flow Control provided for Rollback and Anti
  Message, if Stragglers and antimessaeg generate
  more antimessage during GVT update
• Each new Cycle Starts Fresh without Swarm of
  Anti Message.
• Flow Control Greatly Improve Stability of
  Distributed Simulation
• Memory Usage, anti Message, Over-Optimism

23
Risk and Optimism

• Four input Parameters used in SPEEDES GVT
  Algorithm
• Extend Breathing time Warp Algorithm
• To merge Time Warp
• and Breathing Time Warp Buckets

24
Risk and Optimism

• Input Parameters in SPEEDES
• Tgvt
• Indicate how often GVT is Updated
• Often not requested, because can Detremin
• Ngvt
• Number of Uncommitted Events
• Number of message Received before GVT Updated

25
Risk and Optimism

• Nrisk
• Number of Events Processed beyond GVT
• Each Node allowed to send message with Risk
• Used to Throttle number of Message in Simulation
• if RiskltNgvt , and unprocessed message gtUnsent
  message gtGVT request is Locally generated

26
Risk and Optimism

• Nrisk
• Allowed Event way out in front of simulation
• can Rollback many times
• Without Affecting rest of Simulation
• Keep the number of Anti Message Small.

27
Risk and Optimism

• Nopt
• The Number of Events allowed to Processed on each
  Node beyond GVT.
• Ensure to runaway Nodes when
• Do not use up all their memory
• By processing Events are away out of Simulation
• Good for expensive memory Protection, i.e.
• Cancelback,
• State-Skipping Algorithm

28
Interactive Simulation

• Motivation
• Interactive Synchronization Issues
• Synchronization External Modules

29
Interactive Simulation

• Motivation
• Some Games
• Nintendo
• Sega-Genesis
• Military
• Casino in Las Vegas

30
Interactive Simulation

• Some Problems
• Garbage Collection-Memory
• Rollback
• State-Saving Technique

31
Interactive Simulation

• Optimistic Tools for these Problem
• User can Run Simulation Anywhere and
• Anytime
• Inject
• Rollback
• Rollforward
• Predicate Future Current base on Real-World

32
Interactive Simulation

• As a Example
• Monitor, Control, and Remote of Space Craft
• Conservative Approach use Telemetry to Set of
  current State Value of Simulation
• Optimistic Approach Rollback just things that
  have changed
• Real-World
• Real-Time
• Decision-Aid Tools
• Parallel Processing

33
Interactive Synchronization Issues

• Requirement for Interactive Distributed
  Simulation
• 1- Allowed users to Inject events into Live
  Simulation
• while it is still in Process.
• User participate During Simulation
• 2- Allowed users to Response to output from
  Simulation with Minimally Delay.
• For Highly-Efficient GVT Calculation
• Data Correspond to Past that Processed from Last
  GVT to new GVT.
• Data released from Simulation as events are
  committed.

34
Interactive Synchronization Issues

• 3-Users Be able to Query of the current State of
  Simulated Entities without Delay.
• if Query events is Time-Tagged at GVT it Cannot
  be Rollback
• Optimistic Simulation must wait until GVT is
  updated before releasing data.
• 4- Events should be able to send Data to the
  Outside World without causing Special
  Synchronizations.

35
Interactive Synchronization Issues

• In SPEEDES
• Events are C Objects
• Events can store Output Message.
• Supported by Commit() function.
• Allowed Events to release their Data after GVT
  Updated.
• Allowed events to Send Data to Outside.

36
Interactive Synchronization Issues

• 5-DIS Should support Multiple Users to Enter/Exit
• Forces Hybrid Method in Synchronization
• Dynamic Connection/Disconnection
• In SPEEDES When Data Send
• A Barrier Established to Hold Back GVT.
• Until External Module Reply another Message.
• if External Module Crashed
• gtBarrier Remove from Communication. Figure 1.

37
Interactive Synchronization Issues
38
Interactive Synchronization Issues

• 6- External Module from Multiple Nodes Must
  Maintain Own Estimate of GVT.
• Never permitted to Display info Beyond GVT
• Requirement in this case is very Difficult.
• Message received from various Node.
• External Module Must have own GVT.
• How Knows Time can be Safely

39
Synchronizing External Modules

• SPEEDES Approach for Solving of the Problem
• Determining GVT for External Module.
• Use Especial Gateway (TCP/IP) Communication
• Use Host Router
• SynchObject Provide Simulation Time Info to the
  external module.

40
Synchronizing External Modules

• In Figure 2
• Automatically Open Socket Connection for Each
  Node.
• All Message use the Same socket.
• Host Router Funnel message into Single Stream.
• Starting at Time0
• Each Message Given Time-Tag

41
Synchronizing External Modules
42
Synchronizing External Modules

• Who does it work?
• Simulation Starts Processing at Time0
• A Barrier set up at time-d(Very Small)
• GVT not Permitted to Advanced Beyond this time
  Until External module Connect to Host Router.
• SynchObject Schedule Events for each Node.
• These events Time Tag -d/2
• External Module receive Message like Ping-Ponging

43
Synchronizing External Modules
44
Synchronizing External Modules

• Problem in this Issue
• If a Node send Message with Time-Tag x.
• Host router Not Able to Read message during
  Commit Phase.
• new GVT value now is x1
• A Time Message is sent from synchObject to Host
  Router.

45
Synchronizing External Modules

• Solving
• Simple Mechanism add to Host Router
• Ask for Acknowledgement after last message sent.
• use FIFO.
• Each Node can Guarantee its Message.
• Use Global Synch Guarantee Acknowledgement for
  host Router.

46
Scalable Communication

• Non-Blocking Synchronization
• Node be able to Request Global Synchronization
  Without Blocking
• Without Stopping Event processing
• By Define nb_sync, and nb_check

47
Scalable Communication

• Non-Blocking Synchronization Use in
• Network Workstation
• Shared Memory
• Global Reduction Networks
• Hypercube, Mesh, and Other Parallel Computer By
  Tree Structure, Root Issues to other Node

48
Scalable Communication

• Global Reduction Reduce Integer or Double Values
• i.e1-Determine GVT as the Min Time for LVT Node.
• 2- Determine how many Message Still in Transit,
  by each Node Sent/Received
• Number of Message in TransitGlobal Sum(send by
  Nodes)-Global Sum(Received by Nodes

49
Scalable Communication

• Multirouter This Operation Used in
• Fixed Time bucket
• Breathing Time Buckets
• Breathing Time Warp
• SPEEDES
• Hypercube By Crystal Router Algorithm

50
Scalable Communication

• Multirouter
• In SPEEDES Intel Paragon
• Processors save Messages in Local array of
  Buffers
• When Buffers dedicate to each rest n-1
  destination processors

51
Scalable Communication

• Asynchronous Message sending
• Message must be send Reliably
• Broadcast must making the best of network
• Non-blocking mechanism message sending must be
  use to ensure for space full on another Node.

52
SPEEDES Algorithm

• New SPEEDES, Featured in Breathing Time Warp
• Events Processed in cycle define by GVT Update
• At Start Each Node can request GVT update by
  these conditions

53
SPEEDES Algorithm

• Tgvt seconds have Elapsed since the start of the
  cycle.
• Ngvt Locally Uncommitted events have been
  processed.
• Ngvt Message have been Received Locally.
• The Event Horizon has been crossed.
• The Node has reached its End Time.

54
SPEEDES Algorithm

• Event-Horizone Broadcast their time to other
  Node
• First Nrisk released by Risk.
• Rest held back until new GVT updated
• Nopt stope Node processed that Uncommitted.

55
SPEEDES Algorithm

• nb_sync() Request for GVT Update, then continues
  to Process
• Find_gvt()
• fisrt sets gvtupadate flag
• Flush out all of the message that are still in
  Transit, by calling message(), and antimessage().
• Enter Fuzzy barrier
• Continuing processing

56
SPEEDES Algorithm

• After GVT update
• Each Node goes for locally processing event
• With Time TagltGVT
• Release generated message to
• MultiRouter
• Commit() routine called to permit message to
  released outside safely.

57
SPEEDES Algorithm

• Speedes algorithm
• C_BTW_EVTQflnd_gvtO
• //Set the GVT update flag so that messages will
  not be
• //sent when processing events
• gvtupdate 1
• //Process events while flushing out all of the
  messages that
• white (1)
• //Read messages and antimessages
• messagesO
• antimessages( )
• //Enter the fuzzy barrier and continue processing
  events
• //risk-ree while also checking for messages and
  antimessages
• nb_syncO
• while (nb_checkO)
• process eventO
• messagesO
• antimessagesO

if (twosmess-gtcheck_messcountO O) break GVT
SPEEDES..Qheap.get..timeO if (event_horizon lt
GVT) GVT event_horizon if (GVT gt tend) GVT
tend //Check if barriers have been set up for
external messages. //We can't let GVT advance
beyond the time of an expected //message from the
outside world. tblock objects-gtget_tblockO if
(tblock lt GVT) GVT tblock //The last step is
to perform the global reduction operation
to //determine the minimum GVT value from each
node. scombine( ( int ) gvt, MINDBL, sizeo.l(
double), l ) ff Reset the GVT update
flag. gvtupdate O
58
Performance of SPEEDES Algorithm

• Performance
• 6 node shared memory using an 8 node sun
  workstation
• 6 node distributed shared memory
• 6 node Intel Paragon
• 64 node Intel Paragon

59
(No Transcript)
60
performance
61

• Minimally Algorithm for Global Virtual Time

62
Minimally Algorithm

• LVT Local Virtual Time
• Each Process Indicates Simulation Time.
• Time Warp Indicate at what Simulation Time the
  Event occurs.
• Checkpoint, State Save Copy of all Events.
• Repeatedly calculate GVT during Simulation.
• Stragglers Events that Result in Causality
  Error.

63
Minimally Algorithm

• Exact_GVT No Process will ever Roll Back LVTltGVT
• Impossible to determine exact_GVT.
• Latency of GVT Delay between occurrence of
  exact_GVT, GVTgtx.

64
Minimally Algorithm

• TpWorst case Time required to execute a
  Send/Receive Operation.
• TmWorst Case Transmission Delay
• TVTTarget Virtual Time.
• In this Algorithm Any Process can be Initiator
• Initiator schedule a special event at all
  processes to execute TVT.

65
Minimally Algorithm

• Important Character in this Algorithm
• Minimally Delay
• Specification of TVT to compute value of GVT
• Provide Feedback Mechanism.

66
Minimally Algorithm

• Related Work
• Real Time Each Process determines VT
• At RT, VT is Equal to
• Timestamp of all its unacknowledged Events.
• And LVT.

67
Minimally Algorithm

• Interval Process
• Include Start(i), and Stop(i), i e LP.
• Must Common Share a real time RT.
• Each Process knows RT That occurs in Interval.
• But doesnt know exactly where.
• All process calculate VT(i), and forward to
  Initiator at Stop(i)

68
Minimally Algorithm
69
Minimally Algorithm
70
Minimally Algorithm

• Four Phase for Calculation GVT
• Start and Stop Phase to generate Start(i) and
  Stop(i).
• COLLECT Phase To collect the information needed
  for calculate GVT.
• NOTIFY Phase To notify all processes of the
  update GVT.

71
Minimally Algorithm

• Broadcast Algorithm
• By BellenotBel90.
• Uses broad cast to create Overlapping Intervals.
• Initiator Broadcast STRAT to all Processors with
  START_ACK.
• Initiator Broadcast STOP Message and wait for
  STOP_ACK.

72
Minimally Algorithm

• Broadcast Algorithm
• Each processor define Start(i), and Stop(i).
• Each processor Calculate VT(i), Immediately after
  Receiving STOP.
• Forward to Initiator.

73
Minimally Algorithm

• Tree Algorithm
• Bellenot Improve Broadcast Algorithm by Binary
  Tree, Instead of START and STOP.
• Two Binary Tree use that Connected together.
• Root of Left Tree sends START to Children.
• Root of Right Tree send STOP to Children.

74
Minimally Algorithm

• Tree Algorithm
• Minimum of VT(i) calculated as STOP propagates to
  Left Root.
• Left Tree determines GVT, when received STOP from
  Children.

75
Minimally Algorithm
76
Minimally Algorithm

• Token Ring Algorithm
• Implement three Phase for three different round.
• When a process receives Token
• Define Start(i) for round n.
• Define Stop(i) for round n-1.
• Propagate GVT for round n-2.

77
Minimally Algorithm

• Algorithm
• LP Set of local Processes.
• IP Initiator Process, IP E LP.
• GVTGlobal Virtual Time.
• TVT Target Virtual Time.
• TARGET Target Event.
• VCUT Cut in Virtual Time

78
Minimally Algorithm

• Each Process must maintain its Rollback Counts
• Each Process must maintain a set of Event Queues.
• Algorithm detect when GVTgtTVT.
• Message are not Acknowledged
• Message delivery is not Ordered (non-FIFO).

79
Minimally Algorithm

• Each process will execute TARGET when its
  LVTTVT.
• IP wait to response to TARGET event.
• If VCUT is in complete then detect is false.

80
Minimally Algorithm

• Latency in this Algorithm is Tm2TpO(TmTp)
• If GVTgtTVT gt send a Message directly to
  Initiator.
• Tm2Tp is Minimum Latency in any GVT Algorithm.
• SendTransitReceiveTpTmTp.

81
Minimally Algorithm
82
Minimally Algorithm
83
Minimally Algorithm

• Advantage of this Algorithm
• Compute TVT close to GVT.
• If GVTgtTVT detected with Minimal latency
• This Algorithm not required Acknowledged
• Eliminate Avalanche Message problem during
  Collection Phase.

84

• pGVT An Algorithm for Accurate GVT Estimation

85
pGVT

• pGVT Passive Response GVT algorithm.
• pGVT obtains accurate estimate of GVT.
• pGVT Reduce the Message Traffic to obtain Global
  Event Information.

86
pGVT

• Design for an Environment where
• Message are not always delivered in order.
• There is a Non Zero Probability of failed Message
  Delivered.
• Used in Time Warp.
• pGVT algorithm operates with a central management
  GVT to calculate new GVT

87
pGVT

• Samadi Algorithm
• Earliest Algorithm to pGVT.
• Central GVT manager send information to trigger.
• After receiving information from all LPs
• GVT manager Computes and Broadcasts a new GVT
  value to the LPs.
• The algorithm required all message Acknowledged.
• Not required FIFO message delivery.

88
pGVT

• Problem in Samadi Algorithm
• Required GVT manager to decide when query all LPs
  to Start another GVT cycle.

89
pGVT

• pGVT Algorithm
• Advantage of pGVT
• Cycle to request GVT information from LPs has
  been eliminated from the GVT management process.
• GVT manager saves LGVT values send by LPs.

90
pGVT
91
pGVT
92
pGVT

• pGVT separates into two functional elements.
• First Function that perform by GVT Management
  Process.
• Second Independent Calculation and Reporting
  LGVT values by the LPs.

93
pGVT

• GVT Manager
• Maintains and Broadcast Global GVT Information.
• Saved all reported LGVT values.
• Computes the Average increase in GVT values
  donated by ?GVT.

94
pGVT
95
pGVT

• pGVT Correctness
• Partial Correctness
• GVT manager Always Maintain the Correct GVT
  value
• GVT value lt exact GVT.
• Exact GVT is Minimum of the Smallest un Process
  Event.

96
pGVT

• Total Correctness
• The GVT that Calculates by GVT Manager will
  Monotonically Increase as the LPs Advance.
• When exact GVT move Forward pGVT eventually
  detects it and Estimate GVT value.

97
pGVT

• pGVT is live ness
• GVT that estimate by pGVT algorithm will
  Monotonically increase with exact GVT.

98
pGVT

• Performance of pGVT
• Total GVT Msgs(Mgvt) Measure of total number of
  message
• Average latency (EGVT-GVT) mean different
  between EGVT and estimate GVT.
• Average Memory (M) Average memory for Saving
  state.
• Total GVT Update (Ncycles) total number of GVT
  updates broadcast
• Total Simulation Time (Tsim) Total Wall Clock
  time spend for simulation.

99
pGVT
100
pGVT
101
pGVT
102
pGVT
103

• Fast Asynchronous GVT Algorithm for Shared Memory
  Multiprocessor Architectures.

104
FAC Algorithm

• Based on Tiered Memory Management
• Set of distributed Buffer Pools
• Central Pool
• Each processor takes Buffer from only private
  Pool.
• Put back Reclaimed Buffers to its own Pool.

105
FAC Algorithm

• Processors (PEs) Communicate via share memory.
• Each PE Has Two SITES, where Message or Events
  may exist.
• Input Message queue (input site)
• Event List.

106
FAC Algorithm

• Each Process has one Input Queue, that
  accommodate positive message and anti-message.
• Message directly delivered to destination input
  queue by PEs.
• Concurrent control to input queues are
  implemented, e.g. Lock Protected.

107
FAC Algorithm

• MTVk Minimum receive time of all message held in
  input queue of PEk.
• LVTk Minimum receive time all events scheduled
  for PEk.
• GVTk Minimum LVTk on PEk during GVT Computation.

108
FAC Algorithm
109
FAC Algorithm

• Performance
• Cost of GVT calculation in FAC is low.
• Global cost consist of the cost of GVT
  calculation.
• Cost of Buffer acquisition
• Goal was to study effect of the number of event
  buffers.
• Execute in 8 processors on SGI Power
• Model is 7 dimension Hypercube network.
• 128 node
• 2048 message.

110
FAC Algorithm
111

• Non-Interfering GVT Computation via Asynchronous
  Global Reductions

112
Non-Interfering GVT

• Introduction
• Two Criteria for GVT Computing algorithm
• Number of Message required to compute GVT
• Accuracy of the computed GVT.
• i.e. how close the compute value is the actual
  value.

113
Non-Interfering GVT

• Importance of Algorithm
• Previous Algorithm use host communication network
  to compute GVT
• Here Does not use the Host Communication
  network.

114
Non-Interfering GVT

• Effects of GVT Computation
• Generates extra message in the interconnection
  network.
• In some GVT algorithms, LPs stop simulation to
  Compute GVT. (slow down simulation)
• Algorithms are time-consuming

115
Non-Interfering GVT

• Hardware support for PDES
• Speed
• Scalability
• Adaptability
• Generality
• Low Cost

116
Non-Interfering GVT
117
Non-Interfering GVT

• ALUs Hardware contain Programmable ALUs to
  support variety of application

118
Non-Interfering GVT

• GVT Algorithm
• Host Processor Algorithm Communicate with its AP
  by labeled Communication in its FIFO.
• HOST_PROCExecute event loop.
• SEND_MSG Send message to APs (Auxiliary
  Processor)
• ROLLBACK
• RCV_MSG

119
Non-Interfering GVT

• Auxiliary Processor Algorithm
• AUX_PROC Reading the output state vector of the
  PRN
• DO_ACK perform the acknowledgment of messages
  through the PRN (Parallel Reduction network).

120
Checkpoint

• Selecting the Checkpoint Interval in Time Wrap
  Simulation

121
Checkpoint

• Problems
• State Saving of logical processes
• Update State saving
• Rollback Behavior, and Overhead

122
the Checkpoint Interval

• In Time Warp parallel Simulation, the State of
  each process must be Save (Checkpoint) regularly
  in Rollback.
• Checkpoint Interval is a tuning Parameter of the
  Simulation.

123
the Checkpoint Interval

• Lin and Lazowska
• Proposed a Model to drive checkpoint
• By assuming the rollback behavior of Time Warp.
• This rollback is not affected by Frequency of
  Checkpointing.
• Indicate Sate Saving and Restoration have effect
  on performance of Time Warp.

124
the Checkpoint Interval

• Must Reduce Overhead of state Saving and
  Restoring State.
• Rollback Overhead Comprise
• State Saving (i.e. Checkpoint)
• State Restoration (i.e. Cost associated, and
  recovering)

125
the Checkpoint Interval

• Two Approach of Reducing Rollback Overhead
• 1- Accelerate the State Saving Process. develop
  by Fujimoto
• 2- Reduce the Number of State Saving Operations

126
the Checkpoint Interval

• Coasting Forward The Events with
  T1ltTimestampltT2 that re-execute.
• fig 1, p3

127
the Checkpoint Interval

• Checkpoint Model
• Purpose is to estimate Rollback overhead.
• Three Phase
• Coasting Forward
• Normal Forward Execution
• Rollback

128
the Checkpoint Interval

• fig 2,p 4

129
the Checkpoint Interval

• dsoverhead of saving a process state
• deExpected event execution time.
• table1,p8 with
• formula Xn1

130
the Checkpoint Interval

• Conclusion
• Changing the checkpoint Interval reduce State
  Saving Overhead.
• Even number of Rollback Increase.
• To reduce the total execution time is desirable
  to select checkpoint.

131
the Checkpoint Interval

• fig 3, p-9

132
the Checkpoint Interval
133
the Checkpoint Interval
134

• Adaptive Checkpoint in Time Warp

135
Adaptive Checkpoint

• Define a method that allows Checkpoint Interval gt
  1 as Sparse Checkpoint
• Sparse Checkpoint Effects on Performance

136
Adaptive Checkpoint

• Sparse Checkpoint
• Events have not yet been processed
• Events have been processed, but not Checkpointed
• Events have been processed and Checkpointed
• Reduce Memory for xgt1 with 1/x factor.

137
Adaptive Checkpoint

• fig 1,p-110

138
Adaptive Checkpoint

• Related work
• By Lin Checkpoint Interval
• Lower and Upper bound of checkpoint interval
• Rollback behavior not affected on performance.

139
Adaptive Checkpoint

• Adaptive Checkpoint
• Estimate the execution time
• Consume Memory usage
• Define a snapshot model
• At snapshot time LP processed n Events with
  timestampgtGVT
• The memory consumed by the LP for its history at
  the time of snapshot is M(x) x minimize the M(x).

140
Adaptive Checkpoint

• fig2,p-112

141
Adaptive Checkpoint

• Conclusion
• Sparse Checkpoint affect on performance of Time
  Warp.
• Improve Memory Consumption
• Improve Execute Speed
• Overhead is for adaptive checkpoint is low

142
Adaptive Checkpoint

• Define a method that allows Checkpoint Interval gt
  1 as Sparse Checkpoint
• Sparse Checkpoint Effect on Performance

143
Adaptive Checkpoint

• fig 3,4,5 p-116

144
(No Transcript)
145
References

• Global Virtual Time and Distributed
  Synchronization. Jeffrey S. Steinman Craig A.
  Lee Linda F. Wilson David M Nicol
• An Algorithm for Minimally Latent Global Virtual
  Time. Alexander I. Tomlinson Vijay Garg

146
References

• pGVT An Algorithm for Accurate GVT Estimation.
  Loy M. DSouza, Xianzhi Fan, Philip A. Wilsey
• Non-Interfering GVT Computation Via Asynchronous
  Global Reductions. Sudhir Srinvasan, Paul F
  Reynolds.

147
References

• Selecting the Checkpoint Interval in Time Warp
  Simulation. Yi-Bing Lin, Brun R. Preiss, Wayne M.
  Loucks Edward D. Lazowska.
• A fast Synchronization GVT Algorithm for Shared
  Memory Multiprocessor Architectures. Z. Xiao F.
  Gomes B. Unger J. Cleary