This preview has intentionally blurred sections. Sign up to view the full version.View Full Document
Unformatted text preview: CS-350: Fundamentals of Computing Systems Page 1 of 10Lecture Notes © Azer Bestavros. All rights reserved. Reproduction or copying (electronic or otherwise) is expressly forbidden except for students enrolled in CS-350. Discrete Event Simulation As it should be obvious by now, models that are amenable to analysis, such as queuing models, ignore (or abstract out) many of the details often present in real systems. For that reason, we often rely on simulations. In a simulation, a more detailed model of the system is allowed to “execute” as a program and observations made can be used to make conclusions about the system being modeled. At this point, it makes sense to distinguish between two types of simulations. Continuous Simulation There are many instances in which the state of the system changes continuously. In other words, it is not possible to attribute changes in the system to discrete instantaneous events. As an example, consider how one would model and simulate the “weather” (for weather forecasting purposes, let’s say). Clearly, changes in temperature, wind, etc. are governed by continuous processes, typically modeled by differential equations. Other examples of continuous simulations are those used to evaluate electric properties of VLSI circuits. Given that the underlying processes are changing continuously, to simulate such systems we typically approximate the time continuum with a discrete periodic simulation by using “ticks,” reevaluating the system every tick. Discrete (Event) Simulation A discrete event simulator assumes that the state of the system changes as a result of specific events and that it remains unchanged (static) between events. Furthermore, events are assumed to be instantaneous and thus consume 0 time. Clearly, discrete event simulations will be useful to simulate systems for which it could be safely assumed that the concept of an event exists. The operation of a clocked system (such as a CPU) is such an example, where the only time the system changes is when the clock fires. Another example, of course, is queuing systems. Here it is clear that the state of the queues in the system will not change unless an event (such as a birth or death) occurs in some queue. In a computing system, it is natural to assume that changes in the state of the system will be due to specific events (e.g., arrival of a packet to a router, completion of service from an I/O device, etc.). Thus, for the purposes of the simulation, the state of the system remains constant between events, so one is not interested in taking into account this inactive time. As such, when an event has been “processed” (i.e., accounted for), the simulation time is incremented to the time of the next event and that event is then “processed.” There are two general approaches to the design of a discrete event simulator: (1) the event-based approach, and (2) the process-based approach. CS-350: Fundamentals of Computing Systems Page 2 of 10Lecture Notes...
View Full Document
This document was uploaded on 04/14/2011.
- Spring '09