Discovery Tuning

The Discovery Tuning step determines how long the discovery will last, how many computational resources will be consumed, and how accurate the result will be, effectively answering the "How to discover?" question. The following parameters are introduced to provide control over the discovery process.

Scanning comprises many individual tasks for detecting particular services running on individual devices. Since each of these tasks usually involves relatively long delays (from hundreds milliseconds to several seconds), executing them sequentially can take a while. Instead, they can be executed concurrently for a significantly reduced total discovery time.

Concurrent scan is executed by several simultaneously running threads. The total number of the parallel threads is determined by Concurrency (Thread Count) parameter.

Having too many threads would also defeat the purpose. Your processor will be struggling to keep up with the multiple threads (for example, 2000 threads on a dual-core system) and discovery performance will degrade.

For choosing the thread count you should consider number of hosts to be scanned, along with available resources and system limits. This is case-specific parameters, and it's impossible to recommend a concrete algorithm for determining thread count "in general". The following rules of thumb can be recommended here:

•	The thread count should be selected with respect to the system limits and recommendations (e.g. few hundreds on desktop Windows OS).

•	Respecting mentioned limitations, the thread count can be selected close to the number of hosts to be scanned, but not exceeding it.

•	If other processes are running on your system, you may have to reduce the number of threads. Consider what else is consuming system resources beyond AggreGate.

Threads	Discovery Performance
10	Slow discovery with minimal overhead, suitable for small networks.
100	Optimal value for most networks, average overhead.
1000	Large overhead and heavy CPU load (up to 100%). Suitable for large networks.

As in some circumstances discovery can take a very long time, it can be explicitly limited by Maximum Total Discovery Time parameter. As soon as discovery time exceeds this threshold, the scan process will be compulsory finished. In this case the scan result will include all devices and services discovered by the time.

Time limits can be applied not only to overall discovery process, but also to single-host scanning tasks. If the scanning of a particular host is not finished within the Maximum Single Host Discovery Time period, it is stopped and denoted as unfinished. The discovered services will be kept for result processing stage.

Being potentially a very long process, full scanning of services is preceded by online status detection for each of the specified hosts. By filtering out "dead" (offline) addresses, we can significantly reduce the duration of discovery process. However, this can cause inaccuracy since some existing hosts may decline ping requests.

The Discover Ping-Failed Devices parameter allows to choose between speed or accuracy. If the parameter is disabled, the scan will ignore the hosts not answering ping requests in favor of speed. Otherwise, all specified hosts will be fully scanned, providing more accurate results.

It is often desirable to use descriptive host names instead of flat IP addresses where possible, i.e. automatically assign descriptions to discovered devices. AggreGate Network Manager supports three methods for this:

Assign directly a provided IP address (or host name) as a description for the discovered device. This is the fastest but the least descriptive method. In some cases network administrators prefer to describe device accounts with their IP addresses as they can form a well-composed system and provide uniform host-identification structure.

2.	Use reverse DNS name resolution to find a fully qualified domain name for the provided IP address. Reverse lookup queries can be time-consuming, so this method can increase the overall discovery time.

Take advantage of SNMP data by utilizing SNMP sysName variable as device account description. It keeps "an administratively-assigned name for this managed node" (see RFC1213), and often (by convention) this is the node's fully-qualified domain name. SNMP requests are typically faster than reverse DNS lookup, so this method can improve discovery performance compared to the previous method. AggreGate Network Manager will still use reverse DNS lookup for devices that doesn't support SNMP.