CS457 - System Performance Evaluation - Winter 2010

Public Service Announcements

  1. Assignment 2.
  2. Final Examination: April 21st, 2010 at 09.00 in the PAC.

Lecture 17 - Examples of Discrete Event Simulation

Structure of Software for Discrete Event Simulation

Two possible approaches

  1. Follow requests (job) through the system
  2. Event-scheduling approach

Event Scheduling Components

  1. Events
  2. Event set - set of events, with a total order

    Two important operations

    1. Remove the earliest event from now.
    2. Insert an event.
      • must have a time greater than or equal to the current time
      • forces time to move forward, i.e. ensures causality

    These will be done equally often (Why?)

  3. Two key assumptions
    1. Events are defined so that the system never changes state without an event occurring.
    2. The response to an event can include schedule other event(s)
  4. Defining system state is the most important aspect of abstraction.

Event Scheduling Program

//* marks parts that do not vary from program to program

Highest Level Description

Initialize( ); //*
while ( ( event = event-set.extract( ) ) ) != nil ) { //*
    clock.time = event.time; //*
    process-event( event ); //*
}
log.terminate( ); //*

Initialization

Initialize( ){
    clock.init( ); //*
    state.init( ); //*
    event-set.init( ); //*
    log.init( ); //*
}

Event Processing

process-event( event ){
    log.update( /* Whatever */ ); //*
    clock = event.time; //*
    state.update( event ); //*
    // Possibly test for termination
}

Server with One Queue

Response variables

Parameters = Factors, which need to be defined

Interarrival
Times
Deterministic Stochastic
Service
Times
 Deterministic Common Very unlikely
Stochastic Possible Very Common

Assumptions

  1. Stochastic things are independent of each other
  2. FCFS scheduling
  3. System starts empty
  4. Infinite population (open model)

State variables

Initialization

clock.init( ) { time = 0 } //*
state.init( ) { n = 0; status = IDLE }
log.init( ) { /* open standard output */ }
event-state.init( ) { event-set.insert( new-event( ARRIVAL, clock.time( ) ) ) }

State & Event-set Manipulation

state.update( event ) {
    switch( event.type ) {
    case ARRIVAL:
        event-set.insert( new-event( ARRIVAL, event.time ) );
        n++; queue.insert( event );
        if( status == IDLE ) start_service( );
        return;
    case DEPARTURE:
        status = IDLE;
        if ( --n ) start_service( );
        return;
    }
}

Utility routines

event new-event( type, time ) {
    this.type = type;
    switch( type ) {
    case ARRIVAL:
        this.time = event.arrival-time( time );
        return this;
    case DEPARTURE:
        this.time = time + event.service-time( );
        return this;
    }
}

start-service( event ) {
    log.update( /* Whatever */ );
    job = queue.next( );
    state.status = BUSY;
    event-set.insert( new-event( DEPARTURE, event.time ) ) 
}

Left as exercises for the reader

  1. Trace through the samples and make certain that it all goes as you expect.
  2. Find out the slightly different termination condition than the example in the notes.
  3. Think about what should go in all the updates of the log.

Important.

Parallel servers: one queue, multiple servers

State variable is number-busy: m

How should it be updated and used?

Finite waiting room

Finite Population Model

We saw this as an application of Little's Law.

Each user does the following

  1. Think
  2. Submit request
  3. Wait
  4. Receive result
  5. Goto 1.

Each request

  1. Wait in queue
  2. Receive service

Note. User's wait time is not the same as request's wait time.

You might think that there are three event types

  1. Arrive
  2. Start service
  3. Depart

But, as above "start service" always coincides with either an arrive or a depart event

One thing that is different:

Tandem Queue

The principle is quite easy

but we would rather do this as one simulation. (Programming with signals is not fun.)

The events in the event set are

What happens for each?

  1. A 1.
  2. Dn
  3. DM
  4. start-Sn

Processor Sharing

Time-slicing model: pre-emptive multi-tasking

For example, three classes of jobs

  1. Jobs with active I/O: long think times, very little processing
  2. Interactive jobs without active I/O: substantial processing that will stop and start at widely spaced times
  3. Batch jobs: which go on for very long times.

Single server, three queues, needs a scheduling algorithm (discipline)

Important state

Initialization

Arrival

Departure

Start-service

Something is unrealistic about this model. What is it?

Something is unintuitive about this model. What is it?

This is always the case.

Return to: