• Acquisition
  The acquisition service implements polling and event listening protocol threads. For full information on how the Acquisition service works please see Section 1.4 Acquisition Stacks.
• Alarms
  The alarms service takes the existing defined alarm set, queries the sets for the alarms, and processes them to see if any of have fired. This service will also launch any applications or perform any actions as required. 
• Discovery
  The discovery service manages object and device discovery requests. It generates expressions, creates receivers, fires them, and constructs the devices that it discovers.
• Operations Grid
  Manages portal to portal proxying, computation, and related operations grid functionality.
• Remote Interpreter
  Provides and manages the interpreter command shell for user application development and inter-portal communication.
• Messaging
  AutoNOC's messaging service processes internal events that make changes to the GUI, object table, and other scenarios.
• Persistence
  The persistence service manages all disk-writing of the operations model. It manages access to the recoiling database, handles requests, caches information, and performs time-delayed writing of historical events and polled data.
• Reports
  Report generation and large-scale multivariate analysis is often a computationally processing intensive task. Because of this, AutoNOC provides a separate multi-threaded report generator to insure that both data acquisition and the user experience with the platform is not affected by report computation.
• Solver
  The solver service spawns many threads related to parallel solving of operations expressions.
• Visualization
  A service is also provided for managing and computing visualizations for sets. This service primarily manages network lay-out and the updating of diagrams.

1.3.1 Services Thread List
Each AutoNOC service can spawn a thread, or many threads. The acquisition service, for instance can spawn quite a few threads for managing the different protocols and events. It is possible for the user to view this internal thread list by clicking on the Services tree item on the Configure tab.

An example services thread list looks like the following:

The thread list shows the name of each thread, the thread ID, it's current status, and some processing statistics in the form Total Run Time { Last Run Time } # Fired ( Firing Per Second ) (Total CPU %). It is possible to use the thread display to get a feel for the different actions being taken by the threads and how it is using CPU power.

AutoNOC sets all of these threads up in such a manner as to maximize their performance when working with servers that have multiple processors.

1.3.2 Thread Scaler
By default, AutoNOC takes a very conservative approach to data acquisition in terms of how much CPU power it can use. For some users however, they may desire higher performance and faster polling rates for the devices. This is especially the case with high-density devices (devices that have very large numbers of probes per device). To handle high density devices, AutoNOC provides a thread scaler capability that will allow the user to spawn many more data acquisition and solver threads enabling it to interact with many more devices at a time.

The thread scaler is adjusted as a property of the Acquisition service. The following screenshot shows the thread scaler.

The thread scaler can be adjusted between 0 and 8. Be aware that the thread scaler is a per-CPU scaler. For instance, with one CPU and a thread scaler of 1, AutoNOC will spawn 2 SNMP threads. With a thread scaler of 1 and with 2 CPUs AutoNOC will spawn 4 SNMP threads. The default value of zero (0) will spawn the minimum number of threads for the software to work.

If you have more than 1 CPU, you should probably set the thread scaler to 1. If you are unhappy with the polling rates being provided, consider increasing the thread scaler which will spawn many more protocol stacks to do more simultaneous polling. In the case of SNMP, with 8 CPUs, and a high thread scaler value, the software can perform 100s of thousands of simultaneous SNMP walks. It can have multiple sessions open on the same device and be walking different parts of the MIB tree at the same time and being doing this on 100s of devices.

The following table shows exactly how many threads AutoNOC spawns for each protocol based on the thread scaler value: