There are several statistics (Poll Service status properties) to watch when setting poll rate times and/or assigning points to different poll frequencies/tuning policies. See the related sections Poll scheduler operation and Poll Service properties for detailed descriptions.
Again, it is important to note that if a driver’s Poll Service uses multiple threads (such as in the Bacnet driver), that
poll statistics reflect the sum of activity for all the threads—there is no way to determine a statistics breakdown for each thread.
A Poll Service with a busy time being near 100% does not necessarily indicate a problem. It just means that the number of objects in the poll queues, along with the configured poll rate times, are causing the poll thread to constantly execute, instead of being able to periodically sleep. This means that the inter-message delay is basically at 0 seconds.
Some protocols, such as Modbus, use a “silent time” to define the start and end of a message. In this case, the inter-message
delay is typically hard-coded as a minimum value. Other drivers, such as the American Auto Matrix PUP driver, include a property
to define the inter-message delay time—in which case the Poll Service will use that setting as its minimum. In these cases,
the inter-message delay may be longer than the configured minimum, but it will never be less than the minimum time.
Note when points are first subscribed, they are initially added to the dibs poll bucket for immediate polling. After this initial poll, they are moved to their assigned poll buckets, which simply results in a longer poll cycle time for that rate bucket.
Typically, there is a “base number” of points that are permanently subscribed, including any points that are linked, and/or have a history or alarm extension. Note these permanently subscribed points will always reflect in their assigned poll rate queue. A good starting point would be to adjust the configured poll rates such that the Busy Time is at 75%, with only these points polling.
Maintaining some free time for the Poll Service should allow subscription surges (users viewing graphics, property sheets, wire sheets, etc.) as new points are processed, without causing a noticeable increase in the poll cycle times. If poll cycle times do change noticeably during normal operations, then it may be necessary to adjust the configured poll rates, such that steady state Busy Time is below 75%.
Assuming that a bucket poll cycle time is approximately equal to the configured rate, and the Busy Time does not indicate that the poll scheduler is constantly polling, then it should be possible to reduce that configured rate value (speed up polling). This should result in quicker poll cycle times, which would be confirmed by seeing the bucket’s actual poll cycle time decrease to something near the newly configured value, along with an increase in the poll service’s Busy Time.
If a bucket’s actual poll cycle time is longer than the configured time, then this indicates that the objects in the poll list are being polled as quickly as the driver can. Decreasing the poll rate value (to speed up polling) has no negative effects on the Busy Time, but it will not speed up the polling process either—unless the quantity of points in that queue is reduced.
If the JACE’s CPU usage is high, and the poll service’s Busy Time is near 100%, then increasing the poll interval rate values (to slow down polling) should reduce both the Busy Time and the CPU usage.
Some drivers use a combination of polling and other mechanisms to update point values, such as the LonNetwork, which uses
nvUpdate rules for bound links. The Poll Service’s Busy Time and poll cycle times do not reflect any statistics regarding
points that update values using these other methods, such as nvUpdates or any similar mechanisms.