Queue Size, Message Rate, Total Time to Complete Messages, and CPU Usage

Queue Size

Messages will generally be queued to prevent 2 messages being sent from the gateway at the same time. The size of this queue needs to be large enough to accommodate all messages. It is recommended to set the Queue maximum size to be approximately 30% larger than the number of messages to be sent per interval.

In the Tridium Jace, the EngineCycleMessageQueue in the JsonToolkit pallete has a hidden slot called Max Size. The default size is 1000 and can be adjusted.

Message Rate and Total Time to Complete Messages

There are two timing factors that need to be checked to maintain reliable data transfer.

a) The message rate (average time between messages arriving at the broker) must be >8ms.

b) The messages must also all be able to be sent within the upload interval, otherwise the message queue will overflow and messages will not be sent.

Generally 20-50ms between messages is recommended where possible.

It is also recommended to use a 20% contingency on total message upload time in case of network issues, i.e. have the total time to send all the messages be less than 80% of the upload interval.

In the Tridium Jace, the EngineCycleMessageQueue in the JsonToolkit pallete has a slot called Rate. This introduces a delay between each engine cycle (a single run through all the programmed functions, where one MQTT message is sent per engine cycle). The default Rate (delay) is 50ms.

CPU Usage

For system reliability it is recommended to not exceed the Gateway’s recommended average CPU usage limit. For a Tridium Jace this is 80%. Once the publishing has been set up, allow the publishing to run for an hour or more, and check the CPU usage. Check that the average CPU usage is below the recommended limit.

a) Split the site up over 2 or more gateways; or

b) Increase the upload interval to a longer period (e.g. change from 5min to 10min);

c) Remove low priority points from the upload (e.g. virtual points that don’t change, low interest equipment points)

Example 1

A small site requires upload of 2700 points on a 5 minute upload interval.

The Queue size should be set to around 3500 to accommodate 2700 messages.

The upload interval is 300s and allowing 20% contingency leaves 240s to send all the messages.

2700 messages within 240s is an average 89ms between messages. The controller is checked and has an average cycle time (the time taken to run through all its functions) of approximately 5ms, so a delay of 84ms between cycles would be required.

In this instance a delay of around 50ms between cycles could be selected, as this is well above 8ms minimum message time, but also allows for more points to be added to the upload in future without having to adjust the cycle delay. The total time to send all messages (on average) is 135s (2.25min).

Example 2

A large site has 3 large buildings and requires upload of 25350 points on a 5 minute upload.

The Queue size should be set to around 33000 to accommodate 25350 messages.

The upload interval is 300s and allowing 20% contingency leaves 240s to send all the messages.

25350 messages within 240s results in an average 10ms between messages. The controller is checked and has an average cycle time of approximately 7ms, so a delay of 3ms between cycles would be required.

In this case the cycle time is a majority share of the time between messages, and cycle time variations may impact transport reliability. It would be recommended to either:

a) Split the site up over 2 or more data sources; or

b) Increase the upload interval to 10min;

c) Remove low priority points from the upload (e.g. virtual points that don’t change, low interest equipment points)

Due to the large number of points being exported in this example, it is also recommended to check CPU usage the MQTT publishing has been enabled. If the CPU average usage is greater than around 80%, the publishing should be shared between two of more gateways.