Previous Page

|

Next Page

Queues with Reneging

When a customer arrives at a facility that includes queues and service, they may choose to enter a queue, if there is room, or leave the facility. Once in a queue, they may choose to leave it if they have waited too long. Not entering a queue and leaving a queue are two types of reneging. This example shows how to model some typical queues with reneging.

The model in Figure 10.1 shows a single queue for three servers. It models the M/M/c/K system where and . This system has Poisson arrivals to a single queue with a capacity of transactions for service by parallel servers. Another way to model this system is with the MServer, as shown in Figure 10.1.

Figure 10.1: An M/M/c/K Model

This model is often compared to one with parallel queues and servers, as shown in Figure 10.2.

Figure 10.2: A 3-Queue 3-Server Model

In this model, the Switch component directs the transaction to one of the three queues. In this case, the transaction is routed to the shortest length queue. This is accomplished with two formulas tied to the switch. A model for this is shown in Figure 3.11.

Another variant on the parallel server models in Figure 10.1 and Figure 10.2 has customers entering a queue and, if they have waited for too long, deciding to switch to another queue. This decision-making and queue-switching policy is more complex, but it can be modeled as shown in Figure 10.3.

Figure 10.3: A 2-Queue 2-Server Model with Reneging

In this model, upon arrival, the transaction is assigned an attribute named "priority," whose value is the current simulation time. This is done in the Modifier component labeled "priority." Next, the transaction goes to a Switch, which compares the two queues and sends the transaction down the path leading to the shorter of the two queues. Next, the transaction encounters a Trigger, which schedules the transaction to balk when it has spent a given amount of time in the queue. The default is a random variable with exponential distribution with mean 1. When a transaction balks, it goes into another Switch, which checks whether the other queue is shorter. If it is, the transaction is routed to the Connector a and goes to the end of the other queue. Otherwise, the transaction goes back into the queue after scheduling, in the Trigger, another future check.