We are planning to use the net_connect probe for Packet loss test (Sending 5 Packets every 30 minutes). Around 2000 target IP's need to be tested for packet loss every 30 minutes. Can you let us know, if one probe can handle this number of tests? What is the maximum number of packet loss tests can be triggered from one probe every 30 minutes?
Unfortunately, there is no simple answer or formula to come up with an answer to this.
there are many variables in play here such as:
1) Available CPU and memory on the robot machine doing the checking?
2) Are the devices being monitored close to the robot or many hops away?
3) How many profiles in use ?
4) how many packets will be sent on each interval ?
5) what interval are these to be checked?
6) are we tracking packet loss only or other metrics from net_connect such as jitter?
7) the delay between packets?
8) number of retries?
Usually, support would suggest that you set this up in your lab on the hardware you expect to use and do some benchmark testing on what you would like to perform.
There are posts in the communities where the client has said they have the following working:
CPS has 4 polling servers running Linux, and the load for the main probes is distributed as follows:
- net_connect (23,554 profiles total): 5889, 5889, 5889, and 5887
- 2 QoS per profile
- Polling interval = 3 minutes
- QoS interval = 5 minutes
Below is one example of how a profile time calculation might work.
1 - The runtime between a profile is 60s;
2 - Delay of 12 sec;
2 - It starts three times ping with 10 second intervals between one and other ping;
3 - Delay 2 sec + 10 sec + 10 sec + 10 sec = 32 sec.
4 - Start packet loss test;
5 - Send four packages with 4 sec interval;
6-32 sec + 10 sec = 42 sec.
7 - + some delays = 50 sec
If the above calculation is less than your interval the profile will not work well.
If you have high failure rates it will not execute regularly as this assumes no timeouts happening.
Development Team has tested and supports around 800 profiles with 5 min interval (default values for retry, timeout, etc), so you can split the profiles to another robots using net_connect if you start to have issues with the probe like false alarms or no QOS data.