Hi,

There are three items to take into account when performing an SNMP set and seeing the result reflected back in the parameter value:

• How fast is the set handled: it could be that a lengthy QAction is busy, or there are a lot of other sets pending to be handled first. This could cause a significant delay before the set is actually sent to the device
• How fast is the device processing the set: it could be that a set of value is executed and when the get is immediately being executed, the device returns the old value. Then the modified value will only be visible with the next polling cycle of the parameter. E.g. I'm setting value "4", when immediately executing a get, the device return "3" because it needs 2s to execute the set. If the poll cycle is 30s then it takes 30s before the get is executed again and the value is reflected in the parameter.
• How fast is DataMiner executing the get: it could be that a large table is being polled and that one needs to be executed first before the get of the parameter is done

Opening the StreamViewer when performing the set could provide a better insight of when the set is being executed and when the get enters back and what the value is.

Regards,

Hi Naveen,

What kind of elements are these, and how long is the delay you see?

For instance, if these are SNMP elements, it could be the round-trip time that causes the delay from the device or through the network. With an SNMP set, we confirm the value on the device through an extra poll, rather than set the value immediately in the element.