Protocol Mode
The NTRACE.OS2 driver is loaded at all times, however it will NEVER be called or executed unless tracing is started. So for the vast majority of the time the impact on CPU utilization is 0%. During tracing, Network Trace must copy part or all of each frame sent or received to the trace buffer. In this case, the effect on CPU utilization will vary with the load on the network. Under heavily loaded conditions, NTRACE will be called more frequently and will thus consume more CPU cycles.
It is possible, in an integrated install where the CPU is already heavily utilized, CPU contention can occur. In these situations, contention will result in lost frames. Under these conditions, closing applications or subsystems that are not necessary may help to reduce the CPU load.
In a 3rd party install, by definition one should not have CPU contention. This is an installation that has NOTHING running except NTRACE. If the network load surpasses the CPU's capability of copying frames, then the only other approach would be to utilize the dedicated option, which eliminates all other protocols from the frame copying process, maximizing the access to the CPU by NTRACE. Remember that NO REMOTE ACCESS to/from the trace machine is possible while dedicated mode is in use.
Service Mode
As a layer in the NDIS networking environment, even when tracing is dormant, every frame sent or received must be processed by NTRACE.OS2. This means that there must be a CPU utilization increase when using service mode. However, this difference is so slight that standard measurement techniques cannot discern the difference. Golden Code estimates this difference to be < 1%.
During tracing, there is an additional impact on CPU utilization due to the additional frame copying that is required. The service mode has been designed and optimized to minimize the amount of processing that occurs during the critical time when the LAN hardware has disabled frame reception. This is specifically designed to minimize or eliminate lost frames under conditions of heavy network load. However, this work is just redistributed to times when the speed of copying is less sensitive.
While tracing under service mode, the same basic guidelines apply as in protocol mode. To enable tracing of the most extreme network loads without losing frames, the optimal scenario is to trace using the dedicated option in a 3rd party install. Under service mode, the dedicated option is very highly optimized for throughput.
When tracing is started, a user specified parameter will be used to create a trace buffer. This buffer is sized in 1 MB increments and can be specified using the tracemb parameter. This buffer MUST BE big enough to hold the volume of traffic which the user is trying to capture. On extremely heavily loaded networks, even reasonably large buffers can be filled in seconds. For example, during a 64 machine WSOD/RIPL boot storm, a 128MB trace buffer can be filled in less than 15 seconds (average 9 MB/second)! This example is quite extreme and for most networks, any buffer size between 32MB and 128MB is quite sufficient. There is no "hard and fast" rule for sizing this buffer. The user MUST know the conditions in which tracing will occur to properly scope the buffer size.
Once the buffer is filled, it will either wrap (if the -m2 option is used) or tracing will stop (if the -m1 option is used). So, in addition to determining the proper buffer size, one must determine what "buffer mode" should be utilized. Wrapping is the most general approach, which allows the trace to capture the last X MB of network traffic, where X = the buffer size chosen.
The hardware requirements suggest a recommended RAM of 64MB. This is only a very general guideline. Each targeted machine must have its peak working set measured. The working set of a machine is the total amount of RAM actually in use at one time. The peak working set can be determined by measuring the working set across the range of uses for which a machine is designed. IBM provides a free tool named Theseus which is ideally designed to assist in this measurement. As of May 5, 2000, Theseus 3.002 is the current version and is available from IBM's FTP site. It is particularly important to force stressful conditions upon the machine when measuring the working set, otherwise the results might be under-estimated.
Once the peak working set is known, then one can subtract this from the total physical RAM to obtain an estimate of free RAM available for a tracing buffer. In most cases, it is highly useful to use a reasonably large tracing buffer, such as 32MB. This allows a large number of frames to be captured, but even this may not be enough on high traffic networks.
For example, at the peak of a 64 machine WSOD boot storm one can see frame rates in excess of 28,500 frames per second and total bytes transferred of 9MB per second. Under these conditions, very large trace buffers are mandatory to capture a reasonable amount of network traffic. Network Trace has been tested using buffers of up to 300MB in size.
It is critical to ensure that the trace buffer is not sized so large as to cause the machine to use virtual memory (to swap). This would have a significant negative impact on the performance of the machine and MUST BE AVOIDED.