STAT.NLM Release Notes - Updated 8/9/93 DOCUMENTATION Documentation for STAT.NLM and DUMPSTAT.EXE is a NetWare Application Note entitled "STAT.NLM: A Tool for Measuring NetWare v3.11 Server Resource Utilization," March 1992. The information in this Release Note updates that found in the AppNote. DUMPSTAT.EXE OUTPUT FILE CONTENTS During the DUMPSTAT process, two variables recorded by STAT.NLM--Number of Polling Loops and Maximum Number of Polling Loops--are removed from the data and replaced with a CPU %Utilization figure. Therefore, the output file includes seven rather than eight columns with the following headings: CPU %Utilization Bytes Received Bytes Transmitted Bytes Read Bytes Written Packets Routed Number of Connections DPATCH.NLM DPATCH.NLM patches the NetWare v3.x disk process. This patch enables NetWare to supply the disk statistics required by STAT.NLM's Bytes Read and Bytes Written columns. Always load DPATCH.NLM before loading STAT.NLM. STAT.NLM TRIGGER ANOMALIES If you are using the start and stop trigger mechanism to define a test duration, you must define a test duration that does not include the current time. For example, if the desired test duration is from 7:30a to 5:30p, then you must manually configure the triggers some time after 5:30p and before 7:30a. Triggers set on the hour are often ignored by STAT.NLM. API TO NETWARE'S INTERNAL STATISTICS VARIABLES NetWare's internal statistics can be exported for use by application programmers. For more information, see "NetWare v3.x Operating System Statistics Exposed!," NetWare Application Notes, July 1991. CPU %UTILIZATION ACCURACY The algorithm used by NetWare to calculate CPU %Utilization includes a subtle caveat (See the Appnote for further detail). The algorithm uses the Maximum Number of Polling Loops statistic as the denominator, so it is the reference point from which the CPU's utilization is calculated. However, the Maximum Number of Polling Loops statistic is only accurate after the CPU idles for one second while STAT is active. In most production environments, both MONITOR.NLM and STAT.NLM provide accurate CPU measurements because the CPU regularly rests within 5% of a complete idle state. When MONITOR.NLM is pre-loaded as part of the server's AUTOEXEC.NCF, the Maximum Number of Polling Loops statistic has many opportunities to become accurate before active users log into the network. In some environments however, especially benchmarks, STAT.NLM can provide inaccurate samples. For example, if the CPU is running steadily at 50% utilization before STAT.NLM is activated, a brief STAT.NLM measurement during the benchmark will be inaccurate because the CPU never hits an idle state and the Maximum Number of Polling Loops statistic will be approximately 50% of its potential. A work-around in this scenario is to activate STAT.NLM before the benchmark is started. This sequence of events allows STAT.NLM to capture an accurate Maximum Number of Polling Loops statistic before the benchmark is begun. Afterward, the CPU %Utilization calculations will be accurate. FUTURE RELEASES We have no plans to release another version of STAT.NLM.