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 this case, the polling service use the inter-message setting as its minimum. In both of these cases, the inter-message delay may be longer than the configured minimum, but it will never be less than the minimum time.
When points are first subscribed, the poll scheduler adds them to the dibs stack for immediate polling. After this initial poll, it moves them to their assigned polling rate group, which results in a longer poll cycle time for the group.
Typically, a network has a base number of points that are permanently subscribed, including any points that are linked, and/or that have a history or alarm extension. These permanently-subscribed points always impact their assigned poll rate group queue. A good starting point would be to adjust the configured poll rates such that the busy time is at 75% when the scheduler polls only these points.
Maintaining some free time for the polling service should allow subscription surges (when users view 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, you may need to adjust the poll rates such that a steady-state busy time is below 75%.
Assuming that the poll cycle time for a rate group is approximately equal to the configured rate, and the busy time does not indicate that the poll scheduler is constantly polling, it should be possible to reduce that configured rate value and speed up polling. This should result in quicker poll cycle times, which would be confirmed by seeing the rate group’s actual poll cycle time decreased to something near the newly configured value along with an increase in the poll service’s busy time.
If a group’s actual poll cycle time is longer than the configured time, 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 effect on the busy time, but it will not speed up the polling process either—unless you reduce the number of points in the queue.
If a controller’s CPU usage is high, and the poll service’s busy time is near 100%, increasing poll interval rate values (to slow down polling) should reduce both the busy time and the CPU usage.