Figure 1 depicts the statistics table on the queues:
 Note that 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 bottleneck 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 (Interarrival time = constantly 1),
 and the "Marketing"process starts every second time unit (Interarrival time = constantly 2).
 So, we are sending twice as many messages as there are "Controlling"process instances, which can receive the messages.
Note
 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 interarrival 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.
See the table below for a description of the statistical elements of queues.
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 runtimes and waiting times of this model
The picture from below shows the model's activity runtimes and waiting times.

Figure 2: Activity runtimes 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 interarrival time values of the two start events (like described above), there will be a nonzero 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.