Omnicomm performance factors

The following factors contribute to Omnicomm performance and CPU usage:

• Polling frequency — Increasing the poll frequency will put a larger load on Omnicomm. Depending on factors, such as number of connections and number of remotes on each connection, Omnicomm may not be able to maintain the desired poll frequency. In this case, circuits can help distribute the load during an entire Omnicomm cycle, or additional Omnicomm processes would be needed to split the load.

• Remote Terminal Unit (RTU) Poll delay — This is the delay between remotes on the same connection. This helps to spread out the polling during an Omnicomm cycle to avoid CPU spikes and to allow more efficient processing from other Omnicomm processes that may be contending for CPU time.

• RTU Intra poll delay — This is the delay between successive access attempts to a remote. Modifying this parameter also allows Omnicomm to spread out the polling during an Omnicomm cycle.

• Configuration of circuits — Circuits are used to group connections so that they are not all polled at the same time. This allows Omnicomm to spread out the polling to be more efficient. All the remotes on connections in a circuit group are polled and the data is processed before moving on to the next circuit group. Too many connections on a circuit can affect the poll cycle.

• Number of remotes per connection — If Omnicomm is unable to complete polling of all remotes on the connection within the desired cycle time, it may be necessary to reduce the number of remotes on the connection by splitting the connection into multiple connections, carefully assigning them to circuit groups, and associating them to Omnicomm instances.

• Number of connections per Omnicomm — If Omnicomm is unable to complete polling on all the connections within the desired cycle time, it may be necessary to reduce the number of connections configured for that Omnicomm.

• Initialization Lock Timeout — RealTime locking contention can occur when multiple Omnicomm processes start up and begin their initialization under heavy load scenarios. If one or more Omnicomm processes fail to start up successfully, consider increasing the initialization lock timeout in small increments (<1000 milliseconds [ms]) until the issue is resolved.