Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Show only
|
Search instead for
Did you mean:
Invite a Co-worker
Send a co-worker an invite to the portal.Just enter their email address and we'll connect them to register. After joining, they will belong to the same company.
You have entered an invalid email address. Please re-enter the email address.
This co-worker has already been invited to the Exchange portal. Please invite another co-worker.
Please enter email address
Send InviteCancel
Invitation Sent
Your invitation was sent.Thanks for sharing Exchange with your co-worker.
📖HomeBack SNMP points have configuration for a timeout and retries. Setting these incorrectly can cause problems with SNMP.
There is only one thread used by the SNMP driver to poll SNMP objects (does not include traps). That means that when ClearSCADA attempts to poll a SNMP device, no other device will be polled until this poll times out or the device replies.
If a retry is specified, each subsequent poll doubles the previous poll's timeout. For example, a point is configured for a timeout of 1S and 3 retries. The first time it is polled the timeout is 1S. Assuming the device fails to reply, it will retry, this time with a 2S timeout. If this again fails it will try again, with a 4S timeout. For the final retry it will have a timeout of 8S.
This means, that before this point fails, it will have used 15 seconds of the SNMP driver, stopping other SNMP points polling, which can cause major problems on a system, especially if you have a large number of SNMP points configured the same and they all try to poll part of a network that has failed or is running slowly.
To avoid problems like this, timeouts and retries need to be configured with the above in mind. If the device is on the same network as the ClearSCADA server, timeouts do not generally need to be any higher than 0.1S and you would normally only need one retry at most.
For devices over a WAN or other slow link then it is suggested that you work out the average "ping time" between the server and device, then add a small amount to the time (+5% or +10%) and use that value as the timeout. A single retry can also be specified if occasional timeouts occur for the wrong reason (i.e. the network is busy and so the packet is just slow).
Having a high timeout and more than one retry is best avoided.