How many profiles can net_connect handle on a single robot

Document ID : KB000115479
Last Modified Date : 20/09/2018
Show Technical Document Details
We are planning to use net_connect probe for Packet loss test (Sending 5 Packets every 30 minutes) .
Around 2000 target IP's need to tested for packet loos every 30 minutes.
Can you let us know, if one probe can handel these many tests?
What is the maximum number of packet loss tests can be triggered from one probe every 30 minuts?
UIM 9.0 and earlier
net_connect 3.33 and earlier
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 othe 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.