Transcript Discrete Event Simulation

Modeling and Simulation - 3
• Simulations Using a Simulation
Environment.
7/20/2015
1
Modeling and Simulation - 3
We study the structure and use of a simple event-driven
simulation environment. It is presented in the textbook as a
reasonable example - containing enough of the facilities needed
to support a large range of different simulations.
To justify the claim, the text goes through four different, and
successively more complex, applications. Further extensions to
the applications - and further applications - are presented in the
problems at the end of the chapter (Ch. 2).
7/20/2015
2
Modeling and Simulation - 3
Discussion of Linked Storage Allocation in C - if needed.
Linked Lists of struct (of records).
Doubly Linked Lists.
malloc, calloc, and static array implementations.
Insertion, deletion and sorted insertion in Linked Lists.
7/20/2015
3
Modeling and Simulation - 3
1: single server queueing system. Implementation using
simlib.
This is a re-implementation of our first queueing example. The
reason for it is that we are familiar with the ideas, states and
requirements - not so say anything about output - and that we
will be able to understand the "translation" to a different API
(Application Programmer Interface) without too much trouble.
Let's re-familiarize ourselves with the states of the system.
Arrival
Departure
Heavy Smooth Arrow: event at end of arrow may be scheduled
by event at beginning of arrow in a possibly nonzero amount of
time.
Thin Jagged Arrow: event at end is scheduled initially.
7/20/2015
4
Modeling and Simulation - 3
The first scheduled event is thus an Arrival Event, which may
schedule another arrival event or a departure event, or both. A
Departure Event may only schedule another departure event.
The API must thus provide us with List Management facilities:
we have a list of events of different types. We also have a list
of "customers" waiting in a queue. And possibly other lists - in
particular we can think of the customer being served as being in
a list (with one or zero entries). This latter list being non-empty
will be equivalent to the server being busy.
What are the facilities provided?
First of all, each item being tracked may have multiple
attributes - time, size, actions associated with it, etc. How do
we represent this?
7/20/2015
5
Modeling and Simulation - 3
• Each record is an array of 10 floating point numbers indexed
from 1 to 10 (index 0 is not used) - the "attributes".
We can see immediately that the decision to create a "general
simulation environment" has already dictated that all
information will be in the form of floating point numbers: no
integers, no strings, no other data types. If we allowed multiple
(or user defined) types in the fields of the record, then we
would have to find more complex mechanisms for comparing,
sorting, etc. - in particular, we would have to allow for user
defined comparison functions. This is not impossible, but
makes the environment harder to design and to debug…
It will also dictate the form of the input files.
• The system will maintain 25 lists of records. The number 25
is arbitrary, with some simulations requiring one or two, and
others requiring more. One list (index = 25) will be the Event
List.
7/20/2015
6
Modeling and Simulation - 3
•List
•Attribute 1
•Attribute 2
1, queue
time of arrival to queue
---2, server
------25, event list
event time
event type
Notice that, in accordance with our earlier statements, the
elements of the server list need no attributes: a non-empty list
means the server is busy, exchanging uniformity of treatment for
a specialized variable (server_status), which may not be
meaningful for other applications.
For each list we need a size (list_size[list], list = 1,…,25) and the
attribute used to sort (or rank) the list (list_rank[list], list = 1,
…, 25).
We also need to know sim_time (the simulation clock);
next_event_type (the type of the next event: arrival or
departure, in this case - associated with a unique integer);
maxatr (the maximum number of attributes in the record - at
least 4, at most 10).
7/20/2015
7
Modeling and Simulation - 3
List insertion and list removal functions will need to be provided,
leaving us with the problem of HOW we communicate between
the inside and outside of a list.
The choice made involves an array (transfer[i], i = 1, …, 10) global variable - into and out of which will be copied the record
attributes, each attribute having a unique index.
Again, the choice of records with only floating point number
fields makes this mechanism reasonable.
We now need some way to determine how insertion and
retrieval will work:
FIRST - symbolic constant - do something with the first record;
LAST - symbolic constant - do something with the last record
INCREASING - insert in increasing order (by given attribute)
DECREASING - insert in decreasing order (by given attribute)
7/20/2015
8
Modeling and Simulation - 3
We finish with three more symbolic constants:
LIST_EVENT - 25, the list number for the event list;
EVENT_TIME - 1, attribute number for event time in event list;
EVENT_TYPE - 2, attribute number for event type in event list.
we are left with the implementation of the list management
functions, but we at least have some idea of what will be
needed.
There are going to be several data gathering functions:
sampst(value, variable) for discrete-time data - e.g. number of
customers in queue;
timest(value, variable) for continuous-time data;
filest(list) for summary data on the number of records in a list.
7/20/2015
9
Modeling and Simulation - 3
Discussion of Simulator Code: run terminated when a
specified number of delays have been obtained.
Individual simulation functions. header, main, init_model,
arrive, depart, report.
The simblib functions used for this simulation: init_simlib,
timing, event_schedule, expon, list_file, list_remove, sampst,
out_sampst, out_filest.
Simulation runs. Using separate random streams for arrival
and service distributions. (different from first simulation)
Input and output files.
Analysis of output.
7/20/2015
10
Modeling and Simulation - 3
2: time-shared computer model.
1
2
Unfinished jobs
3
CPU
Queue
n-1
n
Finished jobs
Terminals
7/20/2015
11
Modeling and Simulation - 3
• It's 1975, your company just bought a big IBM mainframe
(370/195), and decided to join the Michigan Terminal System
consortium - they are among the first developers of a semi-free
(you have to host a meeting at least once) multiuser interactive
terminal oriented operating system. IBM still requires you to
take your deck of cards to the computing center…
•You have to decide how many terminals to buy… You could buy
a few, see what happens, buy a few more, etc… The problem
with this approach is that
a) you will buy too few (many) terminals to begin with.
b) since it takes a fair amount of lead time to get used to the
interactive system, you may find that you will either budget for
too few terminals or that, having bought terminals based on
practical experience, your users become, in time, more
proficient, their time/executable command goes down, and you
have an overloaded system. The latter possibility is not so bad:
just drop the service contract on the terminals...
7/20/2015
12
Modeling and Simulation - 3
You are a conscientious system manager and want to try to see
what the future may bring.
Set up a simulation. Of what?
Each terminal users thinks for a random amount of time - with
some mean and probability distribution. This thinking may
involve typing part of a line of characters on the terminal. At the
end of a line, a carriage return sends the information to the
computer, which has the task of processing it. This could be a
command (e.g., list the contents of directory x), or it could be a
line of text to be incorporated in some document, or,well, YOU
think of something…
Since the reason for moving to an interactive terminal oriented
system is to make every user believe (s)he has complete use of
the computer, every user must be able to receive an appropriate
response in an acceptable amount of time, where acceptable
depends on the task.
7/20/2015
13
Modeling and Simulation - 3
How do we achieve this fiction?
Every task is first enqueued, and then, when it reaches the
head of the queue, it runs only for a small amount of time. If it
manages to finish within that time, the user receives whatever
response was supposed to be returned. If it doesn't, it is
stopped, put back into the queue and another task runs for the
prescribed amount of time (a quantum q). We assume that the
time required to do "management" (the swap time t) is much
less than the amount of time devoted to the quantum.
A small task (add two numbers) will probably take less than the
quantum, and should be seen as instantaneous by the user
(there is the time in queue to consider, but…); a large task
(what are the crash characteristics for the new automobile body
hitting a wall head-on at 80 km/h?) may take several hours. In
the latter case, the user will probably go home, have dinner, go
to bed and expect the run to be completed by the next morning.
7/20/2015
14
Modeling and Simulation - 3
The text gives some numbers:
1) mean time between executable commands: 25 seconds,
exponentially distributed;
2) mean job time 0.8 seconds, also exponentially distributed;
3) quantum 0.1 seconds;
4) swap time 0.015 seconds.
Question: How many terminals can I add to this system, and
still claim an average response time (for everyone) of no more
than 30 seconds?
7/20/2015
15
Modeling and Simulation - 3
System Events:
1
2
Arrival
End
CPU
run
End
Simulation
n
The terminals cause an arrival; the CPU can either re-enqueue a
task (causing an arrival) or it can send notification of termination
(the response) to the user and start another run; or it could
cause the end of the simulation, by noticing that the simulation
termination conditions have occurred.
Event
•2
Description
Arrival of a job to the CPU from a terminal.
End of a "think time"
End of a CPU run, when a job either completes it service
requirement or has received a maximum quantum q
•3
End of the simulation
•1
7/20/2015
16
Modeling and Simulation - 3
How many lists should we use?
List
Attribute1
Attribute2
Time of arrival of job to
Remaining service time
•1
computer
Time of arrival of job to Remaining service time after present
•2
computer
CPU pass - negative if this is last.
•25
Event time
Event type
Where List #1 is the queue, List #2 is the CPU (one item in list
if CPU is busy, none if idle: this is just a representation of the
server using a list), and List #3 is the event list.
Note that in this case the server list attributes are NOT
dummies: there is more information contained, since a task
may have to return to the server several times.
Since we move the information from queue to server and back
to queue, the attributes have been "matched" to ease transfer.
7/20/2015
17
Modeling and Simulation - 3
What do we want to know? The average response time - so we
need to keep track of only one discrete time statistics:
sampst variable #1; response times.
Again we choose distinct random streams for the two random
variables:
stream #1: random think times;
stream #2: random service times.
Notice that the jobs don't know what terminals to be returned to
- this may not be important given the question we are asking,
but might be important in reality: just need another attribute,
the terminal_of_origin.
We now need to design and implement code for the event
occurrences: arrive and end_CPU_run. We will also code a
non-event function start_CPU_run.
7/20/2015
18
Modeling and Simulation - 3
Function arrive
Compute job's attributes
and place it in queue
Yes
Invoke
start_CPU_run
Is
the CPU
idle?
No
Flowchart for arrival
function
Return
7/20/2015
19
Modeling and Simulation - 3
Function
start_CPU_run
Remove job from queue
and compute CPU time
Decrement this job's
remaining service time
Place job in CPU
Flowchart for
function
start_CPU_run
Schedule an end_CPU_run
event for this job on this pass
Return
7/20/2015
20
Modeling and Simulation - 3
end_CPU_run
Remove job from CPU
Yes
Place job at
end of queue
Flowchart for
end_CPU_run
No
more CPU time?
Compute response time of
job and gather statistics
Schedule an arrival event
for this job's terminal
invoke
start_CPU_run
Add 1 to number of jobs
processed.
schedule
Enough jobs
jobs
in queue?
end-simulation event Yes done?
No
No
immediately
Yes
invoke
start_CPU_run
7/20/2015
Return
21
Modeling and Simulation - 3
Discussion of Simulator Code: run terminated when a
specified number of jobs have been completed.
Individual simulation functions. main, init_model, arrive,
start_CPU_run, end_CPU_run, report.
The simblib functions used for this simulation: init_simlib,
timing, event_schedule, expon, list_file, list_remove, sampst,
out_sampst, out_filest.
Simulation runs. Using separate random streams for arrival
and service distributions.
Input and output files.
Analysis of output.
7/20/2015
22
Modeling and Simulation - 3
3: multi-teller banking with jockeying.
This is going to be a multi-queue/multi-server simulation, where
members of one queue can "jump" to another queue under
certain conditions.
Teller access in a bank used to be managed this way, although
the current tendency appears to be to have a single customer
queue being served by multiple tellers.
It would be instructive to compare the results of two
simulations. The jockeying should allow for the teller utilization
to remain fairly constant from one type of service to the other.
What about the customer waiting time?
Is there a good reason for switching to a single arrival queue?
Are there any "subjective" factors that enter into the decision?
For example, if I see someone behind me gain several positions
by "jockeying", I feel somewhat annoyed...
7/20/2015
23
Modeling and Simulation - 3
Simulation time: 9:00AM to 5:00PM + customers in queues
by 5:00PM.
Servers: 5 tellers; exponential IID service times, mean = 4.5
minutes.
Arrivals: exponential IID inter-arrival times, mean = 1 minute.
On arrival, a customer joins the shortest queue, with ties
resolved in favor of the lowest index one (leftmost one).
Jockeying: let ni be the number of customers in front of teller i
(queue + service) at a given moment. If the completion of a
customer's service at teller i causes nj > ni + 1 for some other
teller j, then the customer from the tail of queue j jockeys to the
tail of queue i. If there are two or more such customers, the one
from the closest leftmost (lower index) queue jockeys. If teller i
is idle, the jockeying customer begins service at teller i.
7/20/2015
24
Modeling and Simulation - 3
1
2
3
4
5
Statistics: for 4, 5, 6 and 7 tellers, estimate
a) expected time-average total number of customers in queue;
b) expected average delay in queue;
c) expected maximum delay in queue.
7/20/2015
25
Modeling and Simulation - 3
System Events:
Arrival
Event
Departure
Close
Doors
•1
Description
Arrival of a customer to the bank.
•2
Departure of a customer upon completion of service.
•3
Close doors.
7/20/2015
26
Modeling and Simulation - 3
The lists: with n tellers.
a) lists 1 through n will represent the queues of customers
waiting for service in front of each teller;
b) lists n + 1 through 2n will represent the busy or idle state of
each teller;
c) list 25 will be the event list. Notice that a departure event
requires we know the teller associated with it so we can serve a
new customer from the correct queue and trigger jockeying.
List
Attribute1
Time of arrival
1 to n
to queue
n+1 to
2n
25
7/20/2015
Event time
Attribute2
Attribute3
-
-
-
-
Event type
Teller number if
event type = 2
27
Modeling and Simulation - 3
Since each customer can jump around, we will just keep track of
the time between entering the system in some queue and the
beginning of service at some teller. Each customer carries with
it the entry time (attribute 1).
We notice that sampst carries out three activities:
if(variable > 0) { /* Update. */
sum[variable] += value;
if(value > max[variable]) max[variable] = value;
if(value < min[variable]) min[variable] = value;
num_observations[variable]++;
return 0.0;
}
This means that we will automatically get the sum of
the delays, the max delay and the min delay.
7/20/2015
28
Modeling and Simulation - 3
The (estimated) expected number of customers in queue can be
computed as follows: if Qi(t) is the number of customers in
queue i at time t, the total number of customers in all queues
(at time t) is
Qt   i 1 Qi t .
n
The desired estimator - the average number of customers in
queue during the simulation period is
T
Qt dt

qˆ 
0
T
which can be also obtained as the sum of the individual queue
averages.
We also use two distinct random number streams, one for the
inter-arrival times, the other for the service times.
7/20/2015
29
Modeling and Simulation - 3
We need to design and implement five functions:
main;
arrive;
depart;
jockey;
report.
7/20/2015
30
Modeling and Simulation - 3
Function arrive
Schedule next
arrival event
Yes
Tally a delay of
zero for customer
Is
a teller
idle?
Make the
teller busy
Find the number,
shortest_queue, of the
leftmost shortest queue
Place the customer at
the end of the queue
number shortest_queue
Schedule departure
event for customer
Return
7/20/2015
No
Arrival Function
31
Modeling and Simulation - 3
Function depart
Yes
Make this teller
idle
Is the
queue for teller
empty?
No
Remove the first customer
from this queue
Compute this customer's
delay and gather statistics
Schedule a departure
event for this customer
Invoke
Jockey
Departure Function
Return
7/20/2015
32
Modeling and Simulation - 3
Function jockey
Yes
Remove customer
from tail of current queue
Is there
a customer to
jockey?
No
Is the
No
Yes
teller who just
completed service
busy?
Compute delay of jockeying
Place the jockeying
customer - compute stats
customer at the tail of
the queue of the teller who
just completed service
Make teller busy
Schedule departure event
for jockeying customer
7/20/2015
Return
33
Modeling and Simulation - 3
Discussion of Simulator Code: run terminated when the last
customer who entered before 5:00PM is served.
Individual simulation functions. main, init_model, arrive,
depart, jockey, report.
The simblib functions used for this simulation: init_simlib,
timing, event_schedule, expon, list_file, list_remove, sampst,
out_sampst, out_filest.
Simulation runs. Using separate random streams for arrival
and service distributions.
Input and output files.
Analysis of output.
7/20/2015
34
Modeling and Simulation - 3
4: a job-shop model.
A manufacturing system consists of five work stations
(locations), each with a certain number of identical machines:
Work Station Machines
1
2
3
4
5
3
2
4
3
1
Job Type
Routing
1
2
3
3,1,2,5
4,1,3
2,5,1,4,3
7/20/2015
1
2
3
4
5
35
Modeling and Simulation - 3
• The jobs are assumed to arrive at system with inter-arrival
times that are IID exponential random variables with mean 0.25
hr.
• Each job has a different probability:
Job Probability
1
0.3
2
0.5
3
0.2
• Each job requires a different number of tasks, given in the
previous slide. Jobs are served in a FIFO manner at each work
station (one queue per work station).
• At each machine a job will require a time given by an
independent 2-Erlang random variable whose mean depends on
the job type and the work station to which the machine belongs.
(this is the sum of two independent exponentials with means
half the original mean). Chosen because it matches experiment.
7/20/2015
36
Modeling and Simulation - 3
Job
1
2
3
Mean Service Times for Successive Tasks - hours
0.50, 0.60, 0.85, 0.50
1.10, 0.80. 0.75
1.20, 0.25, 0.70, 0.90, 1.00
• We assume 8 hour days, 365 days in a year. We assume there
is no loss in daily set-ups and tear-downs. No losses due to
breakdowns or machine service.
• We estimate the expected average total delay in queue for
each job type and the expected overall average job total delay.
• We also estimate the expected average number in queue; the
expected utilization and the expected average delay in queues
for each work station.
• Assuming all machines have the same cost, we want to decide
how to add one machine to improve the throughput...
7/20/2015
37
Modeling and Simulation - 3
System Events:
Arrival
of new
job
Event
Departure
from
station
End
Simulation
•1
Description
Arrival of a job to the system.
•2
Departure of a job from a particular station.
•3
End of the simulation.
7/20/2015
38
Modeling and Simulation - 3
• Since each work station must support a local queue, we will
have at least 5 lists - plus the event list.
List
Attribute1
Attribute2
1 to 5 Time of arrival Job type
queues to station
25
Event time
Event type
Attribute3
Attribute4
Task number
-
Job type
Task number
• Time of arrival to station: refers to the arrival time for that
list - each job will have different arrival times as it moves from
list to list.
• Task number: refers to how far the job is on its route - the
pair (job type, task number) identifies uniquely the station at
which the job now resides.
7/20/2015
39
Modeling and Simulation - 3
• We will need to generate three types of random variables:
Stream #
1
2
3
Purpose
Inter-arrival times
Job types
Service times
• The data collection for the statistics is going to be the most
extensive up to now: five queues and three job types, for a total
of eight variables relating to queue delays (discrete statistics):
sampst#
1
2
3
4
5
6
7
8
7/20/2015
Meaning
Delay in queue at station 1
Delay in queue at station 2
Delay in queue at station 3
Delay in queue at station 4
Delay in queue at station 5
Delay in queues for job type 1
Delay in queues for job type 2
Delay in queues for job type 3
40
Modeling and Simulation - 3
• The continuous time statistics we will use filest and timest. To
find the average number of machines busy at a given station,
we will keep track in an array num_machines_busy[j].
timest#
1
2
3
4
5
7/20/2015
Number
Number
Number
Number
Number
of
of
of
of
of
Meaning
machines busy
machines busy
machines busy
machines busy
machines busy
in
in
in
in
in
station
station
station
station
station
1
2
3
4
5
41
Modeling and Simulation - 3
Arrive
Yes
Schedule the next
(new) arrival event
is this a
new arrival?
No
Generate the job type
and set task = 1 for
this job.
Determine the station
for this job
Arrival, part 1
Yes
7/20/2015
Are all
machines in this station
busy?
No
42
Modeling and Simulation - 3
Yes
Are all
machines in this station
busy?
No
Tally a delay of 0
for this job
Place the job at
the end of the queue
for this station
Make a machine in
this station busy and
gather statistics
Schedule a departure
event for this job.
Arrival, part 2
7/20/2015
Return
43
Modeling and Simulation - 3
Departure, part 1
Depart
Determine the station
from which the
job is departing.
Yes
Make a machine in
this station idle and
gather statistics.
is the queue
for this station
empty?
No
Remove the first job
from the queue
Compute delay for job
and gather statistics
Schedule a departure
event for this job
Yes
7/20/2015
Does departing
job have more tasks
to be done?
No
44
Modeling and Simulation - 3
Yes
Add 1 to task for the
departing job
Does departing
job have more tasks
to be done?
No
Invoke arrive with
new_job = 2
Departure, part 2
Return
7/20/2015
45
Modeling and Simulation - 3
Discussion of Simulator Code: run terminated when 365
days have passed.
Individual simulation functions. main, init_model, arrive,
depart, report.
The simblib functions used for this simulation: init_simlib,
timing, event_schedule, expon, list_file, list_remove, sampst,
out_sampst, out_filest.
Simulation runs. Using separate random streams for two
arrival and one service distributions.
Input and output files.
Analysis of output.
7/20/2015
46
Modeling and Simulation - 3
• Efficient event-list manipulation.
Priority queues and their implementation as heaps.
7/20/2015
47
Modeling and Simulation - 3
Problems - Projects. Solving ONE is adequate.
1) (Law & Kelton 2.17) This is combination of several smaller
problems (Problem 4 of the previous lecture set, and problem
2.16 of Law & Kelton), and will count for a project. You must
use simlib - if you use another environment (and it must be a
commercially or academically available one, not just something
you cooked up) you will be expected to give a 30-60 minute
presentation to the class for a full grade.
Description: you should use stream 1 for interdemand times,
stream 2 for demand sizes, stream 3 for delivery lags and
stream 4 for shelf lives of the items.
Problem 4) of the previous lecture set discusses spoilage, and
that idea must be incorporated. The other idea is that delivery
lag is uniformly distributed between 0 and 3 months, so there
could be between 0 and 3 outstanding orders at any one time.
The ordering decision at the beginning of each month is based
7/20/2015
48
Modeling and Simulation - 3
on the sum of the (net) inventory level (I(t) in the previous
discussion) and the inventory on order (ordered but not yet
delivered); this sum could be positive, zero or negative. For
each of the nine inventory policies run the model for 120
months, and estimate:
a) the expected average total cost per month;
b) the expected proportion of time there is a backlog;
c) the proportion of items taken out of the inventory that are
discarded due to being spoiled.
Holding and shortage costs are still based on the net
inventory level.
Solving just problem 4) of the previous lecture set (but using
simlib) will entitle you to 15 points out of the 25 available for
the project.
7/20/2015
49
Modeling and Simulation - 3
2) (Law & Kelton, 2.21) In a quarry, trucks deliver ore from
three shovels to a single crusher. Trucks are assigned to specific
shovels, so that a truck will always return to to its assigned
shovel after dumping a load at the crusher. Two different truck
sizes are in use, 20 and 50 tons. The size of the truck affects its
loading time at the shovel, travel time to the crusher, and
return-trip time back to its shovel, as follows (times in
minutes):
Load
Travel
Dump
Return
7/20/2015
20-ton truck
50-ton truck
Exponentially distributed Exponentially distributed
with mean 5
with mean 10
Constant = 2.5
Constant = 3
Exponentially distributed Exponentially distributed
with mean 2
with mean 4
Constant = 1.5
Constant = 2
50
Modeling and Simulation - 3
To each shovel are assigned two 20-ton trucks and one 50-ton
truck. The shovel queues are all FIFO, and the crusher queue is
ranked in decreasing order of truck size, with a FIFO rule in case
of ties. Assume that at time 0 all trucks are at their respective
shovels, with the 50-ton trucks just beginning to be loaded. Run
the simulation model for 8 hours, and estimate the expected
time-average number in queue for each shovel and for the
crusher. Also estimate the expected utilization of all four pieces
of equipment. Use streams 1 and 2 for the loading times of the
20-ton and 50-ton trucks, respectively, and streams 3 and 4 for
the dumping times of the 20-ton and 50-ton trucks,
respectively.
7/20/2015
51
Modeling and Simulation - 3
3) (Law & Kelton, 2.27) A queueing system has two servers (A
and B) in series (one after the other), and two types of
customers (1 and 2). Customers arriving to the system have
their types determined immediately upon their arrival. An
arriving customer is classified as type 1 with probability 0.6.
However, an arriving customer may balk, i.e., may not actually
join the system, if the queue for server A is too long.
Specifically, assume that if an arriving customer finds m (m ≥
0) other customers already in the queue for A, he will join the
system with probability 1/(m + 1), regardless of the type (1 or
2) of customer he may be. Thus, for example, an arrival finding
nobody else in the queue for A (m = 0), will join the system for
sure (probability 1/(0 + 1) = 1), whereas an arrival finding
finding 5 others in the queue for A will join the system with
probability 1/6. All customers are served by A. If A is busy
when a customer arrives, the customer joins a FIFO queue.
Upon completing service at A, type 1 customers leave the
system, while type 2 customers are served by B.
7/20/2015
52
Modeling and Simulation - 3
If B is busy, type 2 customers wait in a FIFO queue.
Compute the average total time each type of customer spends
in the system, as well as the number of balks. Also compute
the time-average and maximum length of each queue and both
server utilizations. Assume that all interarrival and service times
are exponentially distributed with the following parameters:
a) Mean interarrival time for any customer type = 1 minute.
b) Mean service time at server A for any customer type = 0.8
minutes.
c) Mean service time at server B = 1.2 minutes.
Initially, the system is empty and idle, and is to rum until 1000
customers (of any type) have left the system. Use stream 1 for
determining customer type; stream 2 for deciding on balks;
stream 3 for interarrivals; stream 4 for service at A, regardless
of customer type; stream 5 for service at B.
7/20/2015
53