Queue statistics

Figure 1 depicts the statistics table on the queues:

Only the message receiving activity possesses queues.

There are two queues.
This is based on the following fact:
- Whenever a message or a process instance reaches an activity (that has an incoming message flow) there are two possibilities:
- Either the message is the first entity to arrive or the process instance.
  - If the process instance arrives first, it will have to wait for a message to work off the activity.
  - Otherwise if the message arrives first, it will have to wait for a process instance to pick it up.
The latter construct is depicted in the table above.
In our example model, the messages always arrive first.
Therefore the message queue is the only one with significant statistical information for this model.
As you can see, most of the process queue’s values are zero, though we have got eleven Observations (of removing a process instance from the queue).
But, let us check out the Zero column.
- Its value is also eleven.
- This means each of the eleven process instances (that have been put into the queue) have been removed instantly, because they did not have to wait for a message.

Figure 1. Queue statistics

But…

On the other hand the message queue shows us the bottle-neck of this model.
Here we have also got eleven observations, which is correct, because every time a process instance is being reactivated, it consumes one message (which will be removed from the message queue).
Check out the other values:
- Currently there are twelve messages (Qnow) waiting to get picked up.
- This value matches the maximum number of elements (observed throughout the simulation).
  - This indicates, that if we increase the simulation runtime, the maximum waiting time and with that the average waiting time will also increase.
  - We can explain this correlation by having a look at the general simulation properties.
  - The "Controlling"-process starts every time unit (Inter-arrival time = constantly 1),
  - and the "Marketing"-process starts every second time unit (Inter-arrival time = constantly 2).
  - So, we are sending twice as many messages as there are "Controlling"-process instances, which can receive the messages.

Of course there are models, where this principle of "always arriving first" is not valid and "gets mixed up" due to the stochastic influences on the model.
E. g. change the inter-arrival time of our example model’s both start events to
- a Normal Distribution with a mean value of 2 and a standard deviation value of 0.5.
Check the report and you will notice, that both queues possess significant waiting times now.

Description of the statistical elements of queues:

Title: Name of the queue.
Qorder: The Queuing order: FIFO (First in first out) is the default value and cannot be changed.
Obs: Observed removals of entities.
QLimit: The queue’s limit (maximum number of entities this queue can contain). The default value is unlimited and cannot be changed.
Qmax: The maximum number of entities, this queue contained throughout the simulation.
Qnow: The current number of elements contained in this queue at the simulation stop.
Qavg: The average number of elements contained in this queue throughout the simulation.
Zeros: An element that is instantly removed from the queue without any time consumption is called a zero. (Zero for: spent 0 time units in the queue.)
max. Wait: This value represents the maximum waiting time of an element before getting removed from the queue.
avg. Wait: This value represents the average waiting time of an element before getting removed from the queue.
refus.: The number of elements that have been refused to be inserted into the queue.

Activity run-times and waiting times of this model

The picture from below shows the model’s activity run-times and waiting times.

Figure 2. Activity run-times and waiting times

Contrary to our previous example models, we now have got a waiting time in the bottom row of the table.
Its values (except the Obs) are 0.
There is no time consumption, because our processes do not wait at this explicit activity.
There is always a message available whenever a process instance arrives at the message receiving activity (see Zero column in the Queue statistics table).
If we switch the inter-arrival time values of the two start events (like described above), there will be a non-zero waiting time.
Since this model does not possess any further model dynamics, the activity’s waiting time value should be equivalent to the process queue’s waiting time values. Just try it out.