Request for Help on "How many packets will be sent during a regular ICMP poll?"

It sounds to me they are wanting to know how much bandwidth SolarWinds using across the network. Do you have the Netflow product installed? If not you could use wireshark to get the full count. 

SolarWinds is going to use more than ICMP. It will use ICMP for node up/down but it is also going to query a lot of info via SNMP/Agent/WMI as well so the real amount of traffic would be all of this together from the SolarWinds Server/Polling Engine. Also if you have devices sending Syslog or SNMP that traffic also gets included in the total.  

I have been asked to provide information about the amount of data sent or received during a 120-second or 60-second poll in a poll scenario. Specifically, what is the amount of packets/KB data sent or received during this poll period of 120 or 60 seconds?

I have come across a URL that led me to respond that 1KB of data is sent or received per poll, regardless of whether the poll timing is set at 120 or 60 seconds for ICMP polling.

https://solarwindscore.my.site.com/SuccessCenter/s/article/Impact-of-ICMP-SNMP-and-WMI-packet-sizes-and-processing-requirements-to-bandwidth-usage?language=en_US

In terms of "how much data" the answer is "very little".   The polls are 1k packets and when a successful poll happens, there is 1 packet.

Statistics polls, ie: every 9 minutes by default highly depends on what you are monitoring.   If you're just monitoring a node and no interfaces or volumes, you'd see SNMP queries for CPU, memory, and maybe some other things.   If you're monitoring 2 interfaces with NPM, you'd see a little more to query the interface for packets, errors and probably a few more things.    If you're monitoring 500 interfaces on a switch with NPM, you'd see 250x the previous polling.   If you're using something like UDT, you should see it polling all the interfaces on a switch for MAC address tables, while on L3 switches it will poll for ARP tables.   If you're using Netflow (ie: NTA) you'll see a constant stream of data sources by the device for the interfaces you have it configured on.    WMI for servers is a whole other thing.

But, what do all these protocols have in common?   They are quite simple and try and use the least  amount of data that they can.   Compared to "end-user" data, they'll be minimal and shouldn't impact the network.   But, the .less you monitor, the lower the # of packets.   Even on older, slower, networks, rarely would they impact the link.  Back then we worried more about the CPU on the device than the link itself.   These days neither of those are that worrisome.   

But, an exact answer is difficult to give, because its highly dependent on the environment.

In terms of "how much data" the answer is "very little".   The polls are 1k packets and when a successful poll happens, there is 1 packet.

Statistics polls, ie: every 9 minutes by default highly depends on what you are monitoring.   If you're just monitoring a node and no interfaces or volumes, you'd see SNMP queries for CPU, memory, and maybe some other things.   If you're monitoring 2 interfaces with NPM, you'd see a little more to query the interface for packets, errors and probably a few more things.    If you're monitoring 500 interfaces on a switch with NPM, you'd see 250x the previous polling.   If you're using something like UDT, you should see it polling all the interfaces on a switch for MAC address tables, while on L3 switches it will poll for ARP tables.   If you're using Netflow (ie: NTA) you'll see a constant stream of data sources by the device for the interfaces you have it configured on.    WMI for servers is a whole other thing.

But, what do all these protocols have in common?   They are quite simple and try and use the least  amount of data that they can.   Compared to "end-user" data, they'll be minimal and shouldn't impact the network.   But, the .less you monitor, the lower the # of packets.   Even on older, slower, networks, rarely would they impact the link.  Back then we worried more about the CPU on the device than the link itself.   These days neither of those are that worrisome.   

But, an exact answer is difficult to give, because its highly dependent on the environment.