Hello Dojo,
We currently have a driver with partialSNMP:40. We have noticed that with that setting, we are not retrieving the entire table (there are 80 entries and only receiving 20). But when reducing the size to 20, all keys are retrieved.
I see that the documentation has an example of size 3, is that the recommended size that will always work? Also, is there a reason why it would break when using a size of 40? Is there a limit when using partialSNMP option?
Thank you in advance.
Hi Gabriel,
The documentation may have been written while reflecting on a regression test, these often have small datasets and thus, use small bulk sizes.
Regarding your case, it’s not clear to me if you are experiencing a software issue, or a device not responding as expected?
I don’t think there’s a recommended size, since partialSNMP is intended to improve element-device responsiveness and often depends on things like how the device is behaving, how many columns there are, whether those columns contain large values, etc.
One could make the case that network delay multiplied by the amount of requests should stay below a certain threshold, but then again, the amount of network delay can differ greatly between setups.
Hi Gabriel, is partialSNMP needed in these cases? A well-tuned bulk request (multipleGetBulk, MultipleGetNext) can probably poll this table relatively fast.
Any snmp table setup is somewhat dependent on the context and often needs a bit of fine-tuning to get the fastest polling speed possible. The default bulk sizes are usually a good start, but they don’t work for all devices or tables. I believe partialSNMP is just another tool on top of those polling schemes.
Hello Floris, the main reason we are using parialSNMP is because of the latency from the device when polling, which causes an RTE. So to prevent an RTE from being thrown, we are using this option to break up the table sets and circumvent that alarm from showing up in the console. Is there another way to ignore that alarm? Since we know it will resolve over time.
Hi Gabriel, if the latency is this bad, then the partialSNMP option is indeed what you should use, although I’m a bit surprised at the small size of the table causing these problems.
If you have a particular scenario where you believe DataMiner is not communicating or behaving correctly, please do create a software task for the data-acquisition team. Even if it can’t be simulated with the device simulator, a Wireshark capture can still tell us the actual circumstances to solve, and we may be able to adjust the device simulator for regression testing.
Thank you for the information Floris. The current tables that we are seeing the issue with are relatively small tables, no more than 100 rows and no more than 4 columns. It does seem like it is caused somewhat with the device since I am not able to recreate the issue using a SNMP Simulation. So what you are saying is that using partialSNMP requires tinkering depending on the setup? And if we are using the driver from multiple servers to multiple devices, could the partialSNMP size potentially differ given those factors?