For a typically large scale deployment of 1000 remote monitors, it can take considerable time to collect all of the trace data. For the case of 1000 monitors, each with 12 channels, the system needs to setup and acquire 12,000 unique traces in each collection run. It takes 2 seconds to switch the channel and set the desired frequency range, reference level and trace mode, wait for the sweep to complete, and then retrieve the data. With this setup, we need 24,000 seconds to complete the entire acquisition run. That is almost 7 hours if each is done sequentially.

Trace Acquire uses multiple processor threads so it can simultaneously talk to multiple remote monitors at once. For 24 threads, the total acquisition time is approximately 20 minutes. You can set up to 64 threads; however, the optimal number depends on the speed and processor count of the server running Trace Acquire. The time to collect from each channel may be different than the two seconds used in the example above. It will take longer if you are using Min Hold or some other form of trace math, and also longer if the network connection between the server and the remote monitors has a lot of lag time.

You will need to adjust the acquisition interval and thread count to get optimal performance on your server and network setup. If the data collection run takes longer than the set time, then the next run starts approximately 3 seconds after the previous is completed. The next acquisition run will not launch in competition with one that has not completed.

When monitoring for activity, you will want to scan as often as possible. This means you will accumulate many traces over the course of a few days. Vision trace databases are limited in the number of traces they will hold. This limitation is in place so that Vision can be responsive to user interaction. Each time you click a different channel or monitor in Vision, all of the traces for that channel are loaded, a spectrogram is generated and other work takes place behind the scenes. If the database is too large, it will become sluggish.

Vision limits the number of traces to 10,000 per channel in each database. If you are storing a trace every two seconds, then you reach the 10,000 trace limit in about 5 hours. If you want to collect for several days to thoroughly map out the usage, then you will need to store trace data in multiple databases.

Click the “Automatically archive trace tables” check box to set Trace Acquire to automatically archive trace tables at regular intervals. Set the “Archive every” time interval for doing the automatic archive. If you set the Archive to every 6 hours, at intervals the database will be copied to a sub-folder, and the active trace tables will be cleared for storage for the next 6 hour period. The periods have fixed start and stop times. If you set it for 6 hours, then the database will be archived at 6:00 am, noon, 6:00 pm and mid-night each day while it is running. If you start at 10:00 am, then the first archive will only have two hours of data.

As each trace is collected, it is tested against a limit line mask. If the trace exceeds the mask, that trace is marked as having failed. At the end of each run, a report is generated listing each channel that failed. Depending on settings, the database may store weeks or months of trace data, so the report also includes sections for channels that have failed in the past hour, the past day, the past week, and the past month. Users who want to be notified can register to receive this report by email suing the Email Notification system.
See Setting Up Email Notifications.

There is also a contact for each monitor individually, and an email can be sent just for that monitor when it has a channel failure. The user interface provides a table where contacts are registered and the level of reporting is indicated by checking a box. There is also a check box that enables sending emails. If this is not checked, no emails will go out.

There are several database maintenance features available through the UI. If the check box is unchecked for removing old traces, then nothing will get automatically removed and the trace tables will continue to store old data and grow very large. Keep in mind that a typical installation with 1,000 monitors will store 12,000 traces 4 times an hour. Using rough numbers, that is 50,000 traces per hour, or 1.2 million traces a day. If you store 30 days of data, that is almost 40 million traces in the database. Each trace takes around 4,000 bytes, so we have 160 Gigabytes of data. If you let that go several months without removing old traces, it can become quite large and unwieldy, potentially exceeding space available and certainly affecting system speed and responsiveness.