Stop sequential polling of SNMP points if SNMP device is marked as 'Failed'

[rlao]

Hi,

Due to the single-threaded nature of the SNMP driver, we have backlog issues on our SCADA system when several of our SNMP devices goes offline, because the driver is stuck waiting on timeouts for each individual SNMP point for those offline devices. This is a problem when we have quite a lot of SNMP devices out there on our network.

To address this, we have a logic script that disables all SNMP points of a failed device except for one until that one single SNMP point comes back online, after which the script will re-enable all the other SNMP points for that device.

Is there a way we can achieve something more elegant in the SNMP device settings? Like if the SNMP device is found to be bad, then stop polling all its assigned points until the device health improves again. Or does the SNMP device health in GeoSCADA directly depend on whether those SNMP points are online?

[BevanWeiss · Accepted solution]

I think this is unfortunately just the way the current SNMP driver (and largely SNMP) is..

An SNMP Device (in GeoSCADA) itself is really only a placeholder for an IP address and a base OID.

It doesn't do anything on its own.  You need to have a point associated with it before it starts to do anything.  And I've found that it doesn't do anything 'smart' with collections of points, they still all seem to get treated separately, without any optimisation performed as to their scanning (I can't recall what ability there is in SNMP for this.. I'm pretty sure there is like a 'bulk get'.. which from memory GeoSCADA never uses).

My solution has been to always try to avoid SNMP for anything operationally critical.

I only really use it for monitoring a few UPS status signals (i.e. last test, last test battery life expectancy etc).. critical signals like 'On Battery' I still prefer to get via Modbus / DNP3 to an adjacent controller.

[rlao]

Hi Bevan,

Yes, it seems like the concept of an SNMP device in ClearSCADA is superficial and only serves to improve configuration efficiency, rather than influence the scanning behaviour of the driver. There doesn't seem to be any configuration on the SNMP device/points that I can do to make the scanning 'smarter'.

I've since opened up a ticket to discuss this directly with support, but thanks for reaffirming what I suspected.

[BevanWeiss]

It might end up a little bit 'political' in regards to SNMP improvements.

In the radio space, there are predominantly two competing 'brands'.

Trio, and 4RF.

Trio are a Schneider product, and use Trio Diagnostics (Trio Advanced Diagnostics is the improved driver for it).

4RF use the more industry supported SNMP..

Hence, for Schneider to maintain strong market share in the radio space with Trio, there is incentive for them to NOT have a particularly good SNMP driver.  If there was a better SNMP driver in GeoSCADA, quite a lot of telemetry customers would migrate from Trio radios to 4RF.

I have been asking for an 'Advanced' SNMP driver for over 5 years... unfortunately there have been very few improvements at all to the SNMP driver during that time (whilst the Trio Diagnostics protocol received an entirely new development in the 'Advanced' driver range).

[AdamWoodland]

Every SNMP device should expose the uptime (.1.3.6.1.2.1.1.3.0) so it is not outside the realms of feasibility that if you use the device model (rather than the old way of configuring each point with the host/community/etc details) that when the device "polls" it first does a poll to the uptime and see if that returns valid data before worrying about any attached point. Would probably have to be enabled/disabled by some tickbox though in case something doesn't expose uptime (e.g. restricted by ACLs)

Could be worth adding something to the suggestion forum requesting something like this.