M/M/c Queue Simulation Model

M/M/c Queue: Theoretical Background

This system is a classic example of queuing theory and traffic theory.

It is a multi-server generalization of the M/M/1.

In the limit as the number of servers approaches infinity, it becomes the M/M/∞.

Entities arrive at the queue according to a Poisson process and are served in FIFO order.

Queue capacity and queue timeout are infinite.

Entities from the queue are assigned to one of the C servers.

If an idle server is found, the entity is passed to it, otherwise the entity is placed in a queue.

If several servers are idle, one of them is selected at random.

The service time value of any server is exponentially distributed.

The characteristics under study are the probability of waiting, mean waiting time and mean queue length.

Since the method of selecting an idle server does not affect the characteristics of interest, any selection rule can be applied (not necessarily random).

Watch the learning video about the M/M/c queue model.

M/M/c Model in OpenSIMPLY

The blocks Generator, Queue, Selector and Server are required to describe the model of this system. In this example, the Selector block is introduced to distribute entities.

In Delphi and Free Pascal, these blocks are represented by the TGenerator, TQueue, TSelector and TServer classes, respectively.

The Generator and Server blocks are described in the M/M/1/1 model example, the Queue block is described in the M/M/1 queue model example.

In the model under consideration, the Selector block is introduced.

Selector block

The Selector block distributes entities arriving at its input among the outputs (connection points) according to a specified connection rule. The block scans the connected outputs to find an idle one. For example, the rule may be to find the first available idle block (FirstIdleConnection rule) or to select one randomly among all idle blocks (RandomConnection rule).

The outputs are connected to the blocks. In this example these are the Server blocks.

A block can be idle or busy. If there are at least two idle blocks, the connection rule determines which output should be connected to the input to pass the entity.

Download executable model of the M/M/c queue as an ideal call center.

OpenSIMPLY block simulation model of the M/M/c queue

Model Creation

Since FIFO is the default discipline for the Queue block, it does not need to be specified explicitly.

The connection rule item of the Selector block parameter should be specified with the RandomConnection value. However, because the method of selecting an idle server does not affect the results, the default FirstIdleConnection value can be used instead. Therefore, this parameter can be omitted.

Normally, the array of TServer should be created for the servers. But the but the implementation of the TSelector can create the required number of instances of the specified block class and automatically assign them to the selection points. This means you don't need to declare the variable for array of the TServer.

Let's use the variables Gen, Que and Sel for the instances of the classes TGenerator,TQueue and TSelector, respectively. The TServer class and initial values will be specified as parameters for the TSelector block .

Model Parameters

The following variables and functions will be used for the initial values of the blocks.

Capacity: to specify the total number of entities for simulation (Generator)
NumberOfServers: to specify the number of servers in the system (Selector)
InterarrivalTime: to specify the mean value between entities arrivals (Generator)
ServiceTime: to specify the mean value of service time (Server)
ExpTime: a block function that returns exponentially distributed random values

Model Behavior

The code below defines the behavior of the M/M/c queue as an OpenSIMPLY model.

Gen := TGenerator.Create([Capacity,ExpTime, InterarrivalTime]);     //  Creating a Generator.

Que := TQueue.CreateDefault;                                        //  Creating an infinite FIFO Queue.

Sel := TSelector.Create([NumberOfServers]);                         //  Creating a Selector with default rule.

Gen.Connect(Que);                                                   //  Connecting the Generator to the Queue.

Que.Connect(Sel);                                                   //  Connecting the Queue to the Selector.

Sel.Connect(1, NumberOfServers, TServer, [ExpTime, ServiceTime]);   //  Creating the Server instances and
                                                                    //  assigning them to the Selector.

To compile a model, the code above should be placed in a standard wrapper of a model.

Complete Program Code with Input Data and Results

program MMC;
{$AppType GUI}
{$S-}
uses
  SimBase,
  SimBlocks,
  SimStdGUI;
  
type
  TMyModel = class(TModel)             //  Model declaration.  
    procedure Body; override;
  end;

var
  Capacity,                            //  Model parameters.
  NumberOfServers: Integer;
  InterarrivalTime,
  ServiceTime: Double;
 
procedure TMyModel.Body;               //  Model behavior.
var                                    
  Gen: TGenerator;                     //  Blocks declaration.
  Que: TQueue;   
  Sel: TSelector;
begin 
  Gen := TGenerator.Create([Capacity, ExpTime, InterarrivalTime]);
  Que := TQueue.CreateDefault;
  Sel := TSelector.Create([NumberOfServers]);
  Gen.Connect(Que);
  Que.Connect(Sel);
  Sel.Connect(1, NumberOfServers, TServer, [ExpTime, ServiceTime]); 

  Run(Gen);                            //  Launching the start block.

  Que.ShowStat;                        //  Results.  
end;

begin
  Capacity := 3000;                    //  Initial values of the model.
  InterarrivalTime := 1;
  ServiceTime := 1.3;
  NumberOfServers := 2;

  Simulate(TMyModel);                  //  Starting a model.
end.

To validate the M/M/c queue model, verify its results against the exact formula. Thus, the probability of waiting, mean waiting time and mean queue length can be obtained using the Erlang C formula.

For practical applications, the M/M/c model is often extended to include finite queue capacity and customer abandonment in order to better reflect real-world systems.

See also:

more realistic model of the M/M/c/K queue with finite queue capacity
the model of an M/M/∞ with an infinite number of servers