Abstract:
In a probe system for monitoring and analyzing data flow and associated activities between devices connected in common to a point in a network, the probe&#39;s driver runs in a “Kernel mode” on Windows NT for analyzing packets of data retrieved from the network, whereby programming is provided for operating the Kernel mode driver to monitor the rate of traffic or data packets entering an NIC card buffer, for causing the CPU to respond to an interrupt issued by the NIC everytime a data packet is received at a traffic rate below a predetermined threshold to access data packets entering the NIC card buffer, and to cause the CPU to respond to polling pulses at regular predetermined intervals to access data packets, when the traffic rate exceeds the predetermined threshold, for providing more CPU cycles to analyze the data packets. Processing by the CPU of data packets is terminated if more than a predetermined percentage of the available CPU time between system ticks has been expended, such that the entire CPU time is not consumed by processing received data packets.

Description:
RELATED APPLICATION 
     The present invention is related to the invention of U.S. Ser. No. 09/473,149, filed on Dec. 28, 1999, for “Method and Apparatus For Connection-Oriented Multiplexing and Switching Network Analysis, Management, and Troubleshooting,” which is incorporated by reference herein to the extent it does not conflict herewith. 
    
    
     FIELD OF THE INVENTION 
     The present invention relates generally to methods and apparatus for providing network troubleshooting tools for detecting, diagnosing, and repairing network failures, and more particularly relates to a method and apparatus for dynamically optimizing the central processor unit (CPU) cycles for analyzing data retrieved from the network in a manner for eliminating system freeze (inability to move a cursor with a mouse, for example) under high network load, when monitoring networks such as high-speed connection-oriented multiplexing and switching networks (COMSN), including Asynchronous Transfer Mode (ATM) networks. 
     Many different types of networks have been developed for permitting computers to communicate with each other in an organized manner. One such network for use within the same building by a plurality of computer users is known as a local area network (LAN). After the development of LAN networks, network systems were further developed for permitting computer users over a campus environment, such as those located in a large industrial site. To further extend to communicate across wider areas of the country or world, wide area networks (WAN) and/or ATM networks were developed. As these networks have grown in size and complexity, it became increasingly difficult to troubleshoot, maintain, and optimize the performance of such networks, particularly wide area networks. 
     With the invention of the World Wide Web (WWW), and the associated Internet, the complexities of maintaining such world wide advanced data communications far exceed the complexities of the largest WAN systems or networks. To improve communication over the Web or Internet, the ATM system was developed for providing technology for simultaneously transmitting data, voice and video traffic, and information over high band-width circuits. An ATM system network is one example of a high-speed connection-oriented multiplexing and switching network developed for the WWW. In the prior art, hardware has been developed for ATM systems, in conjunction with associated software platforms, to form a communications architecture based on the switching and relaying of small units of data, typically called “cells”. These “cells” may also be grouped into frames or “packets”. ATM systems or networks incorporate technology that advances the state-of-the-art to include a protocol structure for effectively integrating voice, data, and video over the same communications channel at virtually any speed. Other known services for providing data communication, such as the Internet, Internet protocol (IP), frame relay, Switched Multimegabit Data Service (SMDS), and Ethernet, cannot provide the aforesaid integration of voice, data, and video over the same communications channels, as provided by ATM-based services. 
     A In other words, an ATM network consists of configurable networks between source devices and destination devices, with the network being formed by switches interconnected by links. Typically, cells of data which are 53 bytes in length, also grouped as packets, are routed by the switches. A virtual circuit (VC) is established between source devices and destination devices, and the cells or packets are routed across these virtual circuits. One or a plurality of links and switches typically comprise a virtual circuit. Note that a plurality of virtual circuits can be routed across a single link, the latter not being dedicated to any single virtual circuit. 
     Network Associates, Inc., of Santa Clara, Calif., has been in the forefront of technology for many years in developing and providing software for managing and trouble-shooting computer networks. The software is known as Sniffer Software. The most recent Sniffer systems or software readily permit LAN and WAN networks to be rapidly trouble-shooted for resolving problems in the associated network that are interfering with user communication within the network. Network Associates, Inc. (hereinafter NAI), has developed a Sniffer Enterprise Expert System that provides a probe for the rapid detection, diagnosis, and repair of network failures. NAI regularly publishes technical white papers on its public web site at http://www.sniffer.com. Once accessed, the site can be searched for a listing of associated papers. Certain of these papers may be of interest relative to the present invention, and are incorporated herein as of the date of filing this Application, to the extent they do not conflict herewith. 
     For the purposes of this invention, a frame is a known data stream that contains a header, a trailer, and data of some type in between the header and the trailer. The combination of the header and the trailer, per frame, specifies the overall length of the frame, including the contents made up of the header and the trailer, as well as the type of data that resides between the header and the trailer within the frame. An ATM Sniffer is a newly introduced product of Network Associates, Inc. that permits a user to extract full duplex or bidirectional individual and successive frames that are being communicated between an ATM host device or switch, and an ATM network to which a number of user devices may be connected. Note that the Sniffer product simply is connected to a subsection of an ATM network, and it is not necessarily extracting frames that are being outputted by host device (s), but frames that are being communicated over a given network path between a number of devices. Note that for the purposes of this Application, connection to an ATM network means connection to a subsection of the network. These devices are ATM devices. Note that an ATM host device can be an individual personal computer (PC) that has a special card installed in it to permit it to interface with an ATM network for the purposes of communicating data. Also, an ATM edge device is a type of server device that permits an ATM network to be connected through the device to a number of work stations, for example, or other computer devices connected into a network that is connected to the server or edge device. Note that there are a plurality of different types of ATM frames, and the present invention can be utilized with any particular type of frame through appropriate design of the software. However, the present invention is not limited to use in ATM Sniffer products, and can be applied for use in other Sniffer LAN (Ethernet, Token Ring, etc.) network analyzers to optimize the allocation of CPU cycles. 
     In the realm of network analysis, there usually exists a passive station somewhere in the network connection that is able to see all traffic on the portion of the network to which it is connected. This is known as promiscuous mode analysis. Typically a network probe is connected to this network such that it is capable of analyzing each data event on the network. As the capacity of corporate and internet networks increase, there exists a point at which the time required to analyze a single network data event (typically a received packet) exceeds the amount of time between such network data events. Therefore, the network analysis probe must employ some method of throttling the CPU to inure that the probe does not spend all of its CPU cycles analyzing data. For this type of probe, it is usually important for it to respond to the particular user interface employed to view the data objects that are created by the network analysis component of the probe. From experiments with a 400 MHz Pentium II computer, it has been determined that 90% of the CPU cycles can be allocated to network analysis. This leaves 10% of the CPU cycles for all user interface software processes. 
     As previously mentioned, network analyzers are employed for use for monitoring and troubleshooting many different types of networks. Examples of such networks with analyzer probes shown installed for such monitoring and troubleshooting purposes are shown in FIGS. 1 through 3. Note that these Probes can be other than an NAI Sniffer Expert System. 
     In FIG. 1, an Ethernet shared media LAN (local area network) is shown to include an “Ethernet 10/100”, for providing bidirectional communication between two user stations  102  and  104 , a server station  106 , and a printer  108 , in this example. Also, an analyzer probe  110  is connected to the Ethernet  100  for monitoring and analyzing data flowing through the network  100 . Note that personal computers are one example of the user stations  102  and  104 , and the server  106 . 
     In FIG. 2, two Ethernet shared media LAN networks, in this example each include three users  102 ,  104 , and  105 , and a printer  108 , communicating over an Ethernet 10/100 network  100 , are each connected to a common 10/100/1000 Ethernet switch  112 , that in turn provides bidirectional communication with the latter via an FDX Uplink  114  (Full Duplex), to a server  116 , and via a Gigabit uplink  118  bidirectional communication with a second server  120 . Also as shown, in this example, an analyzer probe  122  is connected between the Ethernet switch  112  via two FDX Uplinks  114  for monitoring data flowing between Ethernet switch  112  and server  116 . Similarly, another analyzer probe  124  is connected via two Gigabit Uplinks  118 , as shown, for monitoring data or communication between Ethernet switch  112  and server  120 . 
     In FIG. 3, an example is shown of use of analyzer probes  300 ,  302 , and  303  for monitoring data communications or traffic associated with an ATM network  304 . A router  306  is connected via a DS 3  North American Standard Physical Transmission Interface for digital transmission using TDM (Time Division Multiplexing) operating at 44.736-Mbps to probe  300 . Another DS 3  physical transmission interface is used to connect probe  300  to an ATM switch  308 . The ATM switch  308  is connected via an optical carrier level OC- 12  having a transmission speed of 622.8 Mbps to an ATM Network  304 . The network  304  is also connected via an optical carrier level signal OC 3  having a transmission speed of 155.2 Mbps to probe  302 , the latter also being connected by another OC- 3  carrier level signal link to an ATM switch  310 . The switch  310  is also connected via another standard physical transmission interface DS 3  to a router  312 , and via a DS 1  standard physical transmission interface operating at 1.544 Mbps to another router  314 . The ATM network  304  is also connected via yet another DS 3  digital transmission physical interface to another ATM switch  316 , the latter also being connected via a DS 1  standard physical transmission interface to the analyzer probe  303 . The probe  303  is connected by another DS 1  digital transmission interface to yet another router  318 . In the example of FIG. 3, router  312  is associated with New York City, router  314  with Baltimore Md., router  318  with Dallas Tex., and so forth. Note as previously mentioned that the present invention is not limited for use with ATM networks, but can be used with many different networks, for example such as other high-speed connection-oriented multiplexing and switching networks. 
     In summary, the network examples of FIGS. 1 through 3 are shown as examples of typical connection types that are supported by network analyzers or analyzer probes, as indicated. FIG. 1 shows a typical shared media LAN, in an Ethernet configuration. FIG. 2 is an example of the typical switched Ethernet network with a full-duplex uplink or Ethernet trunking uplink to a shared server. Lastly, FIG. 3 shows a typical ATM network carrying data between multiple WAN sites. As shown in FIG. 3, three analyzer probes  300 ,  302 , and  303  are inserted at various points in the network to analyze full-duplex ATM links between ATM switches  308 ,  310 , and  316 , routers  306 ,  312 ,  314 , and  318 , and the ATM network  304 . 
     With further reference to FIG. 3, the following table identifies the types of connections shown therein, in relation to their expected maximum event rates, respectively: 
     
       
         
               
               
               
               
             
               
               
               
               
               
               
             
           
               
                 TABLE 1 
               
               
                   
               
               
                 Connection 
                 Speed 
                 Maximum Event Rate 
                   
               
               
                 Type 
                 (mbps) 
                 (per second) 
                 Time per event 
               
               
                   
               
             
             
               
                   
               
             
          
           
               
                 DS1 
                 1.544 
                 6666 
                 ATM cells 
                 150 
                 microseconds 
               
               
                 DS3 
                 45 
                 210000 
                 ATM cells 
                 4.8 
                 microseconds 
               
               
                 Shared LAN 
                 10 
                 14400 
                 packets 
                 69 
                 microseconds 
               
               
                 Shared LAN 
                 100 
                 144000 
                 packets 
                 6.9 
                 microseconds 
               
               
                 Full Duplex 
                 200 
                 288000 
                 packets 
                 3.5 
                 microseconds 
               
               
                 100 
               
               
                 Ethernet 
                 800 
                 1152000 
                 packets 
                 868 
                 nanoseconds 
               
               
                 Trunking 
               
               
                 Gigabit Link 
                 2000 
                 2880000 
                 packets 
                 350 
                 nanoseconds 
               
               
                 OC-3 
                 155 
                 706400 
                 ATM cells 
                 1.4 
                 microseconds 
               
               
                 OC-12 
                 622 
                 2825600 
                 ATM cells 
                 354 
                 nanoseconds 
               
               
                   
               
             
          
         
       
     
     As shown in the Table, the per-packet of time is very short for many of the networks or network connection types. For example, for a personal computer or CPU that includes a 400 MHz microprocessor, a single instruction can be executed in 2.5 nanoseconds. Accordingly, for the fastest link or connection shown, approximately 140 CPU instructions can occur between packets, which is insufficient to permit analysis of a single packet. Accordingly, in order to provide sufficient CPU instructions to user interface components, it is necessary to provide CPU throttling of the analysis subsystem. 
     SUMMARY OF THE INVENTION 
     An object of the present invention is to provide a method and apparatus for throttling CPU cycles, when required for providing more efficient use of and a greater number of CPU cycles during times of heavy traffic on a network, for permitting an analyzer probe to monitor and analyze a greater number of data packets retrieved from the network being monitored during such times of heavy traffic or data transfer in the network. This is accomplished through use of a method and apparatus that includes two modes of operation. The first mode of operation provides a device driver in an analyzer probe connected in a network to respond to every receive interrupt generated by a network interface adapter card buffer during times of low traffic or data transfers in the monitored network, for transferring data packets received from a receive buffer of the network interface adapter to a RAM buffer for analysis. In the second mode of operation, when the rate of traffic is greater than a preset threshold, the receive interrupts from the network interface adapter card are ignored, and replaced by polling at regular intervals of the received buffer of the network interface adapter for transferring packets to the RAM buffer of the analyzer. Accordingly, under heavy traffic conditions, through use of the present invention, fewer packets are lost by the analyzer. In this manner, more CPU time is made available for performing processing not associated with the analyzer probe. In another important embodiment of the invention, when the time spent by the CPU in processing received data packets, in the first or second modes of operation, exceeds a predetermined percentage of the total CPU time available between operating systems ticks, data packet processing is terminated, to free the CPU to perform other processing. In a Windows NT operating system, for example, the first and second modes of operation are operated in a Kernel mode, and when data packet processing is terminated as indicated, the CPU transfers to a User mode. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     Various embodiments of the present invention are described in detail with reference to the drawings, in which like items are identified by the same reference designation, wherein: 
     FIG. 1 shows a block schematic diagram of an Ethernet shared media LAN; 
     FIG. 2 is a block schematic diagram showing an Ethernet switched network with FDX and/or Gigabit Uplinks to servers; 
     FIG. 3 is a block schematic diagram showing an ATM Network including a plurality of analyzer probes inserted at various points between users and the network; 
     FIG. 4 shows a block schematic diagram of an NAI Sniffer System associated with one embodiment of the invention; 
     FIG. 5 shows an NAI Sniffer Adapter Driver flowchart for one embodiment of the invention; 
     FIG. 6 shows a flowchart of the steps associated with the embodiment of the invention for processor speed calibration; 
     FIG. 7 is a flowchart showing the steps for a procedure generated by the NAI Sniffer Adapter Driver for one embodiment of the invention; 
     FIG. 8 is a flowchart generated by the NAI Sniffer Adapter Driver for an Adapter Driver Deferred Procedure Call for an embodiment of the invention; 
     FIG. 9 shows a flowchart generated by the NAI Sniffer Adapter Driver to provide an implementation of processing performed by a System tick timer( )for an embodiment of the invention; 
     FIG. 10 shows a flowchart generated by the NAI Sniffer Adapter Driver for another embodiment of the invention to create an AdapterProcessReceivedPackets( ); and 
     FIG. 11 shows a flowchart for another embodiment of the invention as generated by the NAI Sniffer Adapter Driver for generating an InterruptEnableDisableThreshold( ). 
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     The description of the present invention is given for an example of use in association with a Microsoft Windows NT® operating system. However, the invention is not so limited, and can be used with any other commercially available operating system. The NAI Sniffer System, as shown in FIG. 4, will now be described in detail relative to the present invention provided via software loaded into and operated by a PC  1 . PC  1  is a personal computer that includes a central processing unit (CPU) loaded with a Windows NT Operating System in this example, and designated by reference numeral  9 . The PC  1  stores in memory the NAI Sniffer Application Software Process, and Windows NT OS software (operating system) in memory. An NAI Adapter Card  22  and all other processes required to support such network analysis application are also included. A statistics buffer memory  2  contains different statistics such as Host Table, Matrix Table, Protocol Distribution, Global Network Statistics, etc. A data connector  3  connects the NAI Sniffer Software Process memory  4  to the Statistics Buffer Memory  2 . 
     The NAI Sniffer Software Process in memory  4  contains the user mode software (User Interface) to the Statistics Buffer Memory  2 , and to the Frame Capture Memory  6  via data connector  5 . It is also connected via data connector  8  to the NAI Sniffer Kernel Software Process Memory  10  to provide the location (memory address) of the Statistics Buffer Memory  2  and the Frame Capture Memory  6  to the NAI Sniffer Kernel Software Process Memory  10 . 
     Frame Capture Memory  6  is a memory buffer used to save captured data frames. Other User Mode Processes  7  are other applications in the PC  1  which require some CPU time to appear to be responsive to the user commands from a mouse and/or keyboard (not shown). 
     The Windows NT Operating System Services are Application Programmers Interface functions available to Kernel Mode Driver programs. These services provide functions which allow Kernel Mode Driver programs the ability to allocate memory, schedule timer operations, register interrupt service routines to specific hardware device interrupts, access registers in hardware devices and other OS (operating system) related functionality used by Kernel Mode Driver programs. 
     NAI Sniffer Kernel Process software in memory  10  is analysis software which updates data in a Statistics Buffer Memory  2 , which contains items such as a Host Table, Matrix Table, and Protocol Distribution objects, and provides Real-Time filtering, triggering, and optionally saves selected data by transfer to the Frame Capture Memory  6 . A data connector  11  provides NAI Sniffer Kernel Software Process Memory  10  access to the Windows NT Operating System and CPU  9 . 
     A data connector  12  provides the control and data flow between the NAI Sniffer Kernel Process Memory  10 , and the NAI Sniffer Adapter Software Driver Process  14 . This provides the ability for the NAI Sniffer Adapter Software Driver Process  14  to inform the NAI Sniffer Kernel Mode Software Process Memory  10  of received data from the network  26  under analysis. 
     A data connector  13  provides NAI Sniffer Adapter Software Driver Process  14  the access to the Windows NT Operating System and CPU  9 . The NAI Sniffer Adapter Software Driver Process  14  consists of software responsible for supporting the NAI Sniffer Media Specific Network Interface Adapter card  22 . This software process must allocate the Card Receive Buffer Memory  18 . It will program the NAI Specific Network Interface Adapter  22  with the location of the Card Receive Buffer Memory  18 , and will accept interrupt notification from the NAI Media Specific Network Interface Adapter  22  when data has been received in the Card Receive Buffer Memory  18 . When data is received, the NAI Sniffer Adapter Software Driver Process  14  will indicate receipt of the data to the NAI Sniffer Kernel Software Process Memory 10 . Note that the Network Interface Adapter card  22  is known also as a NIC card  22 , and in certain applications may include the card receive buffer memory  18 . 
     A data connector  16  connects the Card Receive Buffer Memory  18  to the NAI Sniffer Adapter Software Driver Process  14 . The Card Receive Buffer Memory  18  is a data memory allocated by the NAI Sniffer Adapter Driver Software Process  14  for purposes of direct access by the NAI Sniffer Media Specific Network Interface Adapter card  22 . 
     A data connector  20  provides the bus access between the NAI Sniffer Media Specific Network Interface Adapter  22  and the driver  14 . It provides the electrical connection and appropriate signaling for this connection. Typical bus architectures are PCI, CardBus and ISA. This connection  20  allows PCI Bus-Mastering support which allows the NAI Sniffer Media Specific Network Interface Adapter  22  to directly write received packet data into Card Receive Buffer Memory  18 . It allows the NAI Sniffer Adapter Software Driver  14  to directly access the device registers (not shown) on the NAI Sniffer Media Specific Network Interface Adapter  22 . It also allows the NAI Sniffer Media Specific Network Interface Adapter  22  to interrupt the CPU  1  to indicate events to the NAI Sniffer Adapter Software Driver  14  process. 
     The NAI Sniffer Media Specific Network Interface Adapter  22  is one of several hardware devices manufactured by NAI or an NAI OEM supplier. There are different adapters which support different network topologies (ATM, Ethernet, FDDI, etc). The network connection  24  provides a cable or fiber optical cable connection to the network  26  being analyzed. The network  26  being analyzed is a given network to be analyzed by the NAI Sniffer System. Examples of the types of Networks supported are as follows: ATM, Ethernet, WAN, Frame Relay, FDDI and Token Ring. 
     The CPU throttling of the present invention is illustrated for use in a Sniffer System  50  which operates within the Microsoft Windows NT operating system. As previously described, the OS (operating system) provides services which driver programs use to support network devices. As shown, the typical network device is a PCI Bus-mastering network adapter. Interface adapters which are classified as PCI Bus-Mastering devices have the following properties. First, they conform to the PCI Version  2 . 1  specification of the PCI Special Interest Group. This Group defines a standard method for the electrical and mechanical connections into a standard PC platform. This PCI Bus allows the CPU and its Local Memory to communicate with devices. Secondly, a PCI Bus-Mastering device has the capability to request access to the PCI Bus to become a bus master controller, which allows that device to directly access the CPU&#39;s Local Memory, whenever the device needs to read data from local memory or to write data to local memory. This capability provides the most efficient data transfers between devices and CPU  9  local memory on a PCI bus. 
     A broad description of the control flow of the program during initialization and receive data processing will now be provided. The first two steps occur during initialization, and the last three steps occur during receive data processing. The steps are as follows: 
     1. The NAI Sniffer Adapter Software Driver  14  allocates the Card Receive Buffer Memory  18  for received data. 
     2. The NAI Sniffer Adapter Software Driver  14  programs the registers in the NAI Sniffer Media Specific Network Interface Adapter  22  to DMA (direct memory access) received data to the Card Receive Buffer Memory  18 . 
     3. The NAI Sniffer Media Specific Network Interface Adapter  22  receives data and begins to DMA (direct memory access) the received data to the Card Receive Buffer Memory  18 . 
     4. The NAI Sniffer Media Specific Network Interface Adapter  22  informs the NAI Sniffer Adapter Software Driver  14  of the received data through a Hardware Interrupt to the CPU processor  9 . 
     5. The NAI Adapter Software Driver  14  processes the received data and informs the NAI Sniffer Kernel Mode Software Process  10  of the received data for analysis transferred to Statistics Buffer Memory  2 , and an optional copy to the Frame Capture Memory  6 . 
     As described previously, these steps can consume significant CPU processor  9  time when the network  26  being analyzed is loaded at the maximum. Therefore, the present invention provides a method of CPU throttling for employment by the NAI Sniffer Adapter Software Driver  14  (or in other network monitoring and analysis Systems) to limit the percentage of CPU processor  9  time dedicated to such processing. In addition, the present invention provides a method of reducing interrupt overhead by programming the NAI Media Specific Network Interface Adapter  22  to not generate interrupts for received data when the total number of received events exceeds a threshold. 
     With reference to the flowcharts of FIGS. 5 through 11, the CPU throttling method of the present invention will be described in greater detail. The following parameters are specified to the CPU Throttling implementation. These parameters are provided to control the CPU throttling based upon user input, or experimental data. They are as follows below in Table 2. 
     
       
         
               
               
               
             
           
               
                 TABLE 2 
               
               
                   
               
               
                 Parameter Name 
                 Size 
                 Description 
               
               
                   
               
             
             
               
                 u1CpuPercentage 
                 32 
                 This is an integer number from 0-100 
               
               
                   
                 Bits 
                 indicating the total percentage of the 
               
               
                   
                   
                 CPU time which shall be dedicated to 
               
               
                   
                   
                 receive processing. 
               
               
                 u1IntrEnableThreshold 
                 32 
                 If the total number of packets received 
               
               
                   
                 Bits 
                 during an Operating System Tick 
               
               
                   
                   
                 interval which is normally 10 ms is less 
               
               
                   
                   
                 than this number, the receive 
               
               
                   
                   
                 interrupt will be re-enabled. 
               
               
                 u1IntrDisableThreshold 
                 32 
                 If the total number of packets received 
               
               
                   
                 Bits 
                 during an Operating System Tick 
               
               
                   
                   
                 interval which is typically 10 ms is 
               
               
                   
                   
                 greater than this number, the receive 
               
               
                   
                   
                 interrupt will be disabled. 
               
               
                   
               
             
          
         
       
     
     Variable naming conventions used in various embodiments of the invention are defined as follows: 
     “ulVariableName” is the name of a variable which is an unsigned long integer 32 bits in length. This value will accept a hexadecimal integer number from 0 to 0xFFFFFFFF. 
     “ullVariableName” is the name of a variable which is an unsigned longlong integer 64 bits in length. This value will accept a hexadecimal integer number from 0 to 0xFFFFFFFFFFFFFFFF. 
     “bFlag” is the name of a BOOLEAN variable which can be either TRUE or FALSE. 
     A driver program creates a function that samples an Intel Pentium processor&#39;s internal real-time clock register, for example, such as CPU processor  9 . This real-time clock is incremented by the Intel Pentium processor at an interval of once per processor clock. (For example, the clock is incremented every 1/400,000,000 second for a Pentium system configured to run at 400 MHz). This function is named “GetProcessorTick( )”. 
     A driver program defines a variable “ulSystemTicks” which is incremented once per System Tick. Note that a “tick” is the minimum resolution of a timer, for each occurrence of the associated timing pulse. As will be described in detail with reference to FIG. 9, in step  904  this variable “ulSystemTicks” is incremented once per OS (operating system) system tick. A function named “GetSystemTick( )” will return the value of this variable. 
     As shown in FIG. 5, the NAI Sniffer Adapter Driver  14  registers a function OneSecondTimer( ) in steps  500  and  501 , with Windows NT kernel to be called at one second intervals in step  502 . This function performs two tasks: Processor Speed Calibration, and Per Second statistics. 
     With reference to the flowchart of FIG. 6, the Processor Speed Calibration  600  is defined by steps  601  through  607 . This processing or software routine calibrates the system CPU processor  9 . This routine samples the current processor tick and current system tick over a period of five to sixty seconds, for example. The function employs a state based algorithm to detect the ullProcessorTicksPerSecond (64 bit variable) and the ulSystemTicksperSecond (32 bit variable). It does this by reading the current processor tick and system tick at the beginning of a five to sixty seconds sample period as shown in step  602 , for example. At the end of this period, the current per-second values are calculated from the sample data. This is shown by step  606 . During this processing, the value (ullProcessorTicksLimit) is calculated utilizing the above calculated values and the value stored in the controlling variable called ulCpuPercentage. This value ullProcessorTicksLimit is used by the CPU Throttling loop defined in step 1005  of the flowchart in FIG.  10 . This limits the total number of processor ticks that can be consumed by per-packet received processing for each system tick. In other words, the number of processor ticks between system ticks. As shown by step  606  in FIG. 6, the formula for Processor Ticks Limit is defined by: 
     
       
         (ullProcessorTicksPerSecond*ulCpuPercentage)/(ulSystemTicksPerSecond*100) 
       
     
     As previously described, from experimentation, the ulCpuPercentage control variable has been determined to be optimal at 90 (configuration for 90 percent). In other words, when the time spent by the CPU  1  in processing a received data packets exceeds 90% of the CPU time available between operating systems ticks, data packet processing is terminated, and the CPU is transferred to User mode processing from a Kernel mode. Note that although 90% is preferred, any other percentage value can be used, depending upon the application. Also, note that Kernel mode processing has a higher priority than User mode processing. 
     As shown in FIG. 7, the NAI Sniffer Adapter Software Driver  14  is programmed to create a procedure called AdapterISR( ) shown as step  700 , which gets called by Windows NT programming of CPU processor  9  once per interrupted event as triggered by the NAI Sniffer Media Specific Network Interface Adapter  22 , for carrying out steps  701  through  705  when one of the following events occurs: 
     Received Packet 
     Transmitted Packet 
     Physical Layer Notification 
     ASIC Management Notification 
     For the purposes of this description, only the Received Packet events will be documented. All other events occur at very low frequency. Therefore, their action is simply processed under normal conditions without being controlled or throttled by the methods and procedures defined herein. However, given that received packets are expected to occur at very high rates, the received packet event is processed differently. This function will execute at the Microsoft Windows NT priority level known as DIRQL_LEVEL. When this function executes and determines that the source of the interrupt is a received event, it signals to the Windows NT OS to queue the Adapter driver DPC for execution by the CPU  9 . The AdapterDPC( ), a DPC (Deferred Procedure Call) as defined by the flowchart in FIG. 8 will be queued. 
     As shown in FIG. 8, the NAI Sniffer Adapter Software Driver  14  creates a function AdapterDpc( ), shown by step  800 , that gets called by Windows NT OS at the request of the AdapterISR( ). This function will execute at the Microsoft Windows NT priority level known as DISPATCH_LEVEL. This DPC will call the AdapterProcessReceivedPackets( ) function described by the flowchart in FIG.  10 . 
     As shown in FIG. 9, the NAI Sniffer Adapter Driver creates a function called SystemTickTimer( ) denoted by step  900 . It registers this function with Windows NT OS. This function is called once per operating system tick. As previously described, this time period is approximately 10 ms in the Windows NT OS. As shown, a ulSystemTick variable is maintained for the GetSystemTick( ) function described earlier relative to the flowchart of FIG.  6 . 
     As shown in FIG. 9, the InterruptEnableDisableThreshold( ) process step  901  (described by flowchart of FIG. 11) is called once per Windows NT system tick to perform Interrupt Enable/Disable processing. As shown in steps  901 - 905 , the AdapterProcessReceivedPackets( ) process step  903  (described by flowchart of FIG. 10) is called once per Windows NT system tick to process received packets when the Receive Interrupt is disabled by the InterruptEnableDisableThreshold( ) process step  901 . 
     As shown in FIG. 10, the NAI Sniffer Adapter Driver  14  creates a function known as AdapterProcessReceivedPackets( ) denoted by step  1000 . This function will process, via steps  1001  through  1008 , all received data which has been placed in the Card Receive Buffer  18  by the NAI Sniffer Media Specific Network Interface Adapter  22 . The function  1000  is called either from the DPC (Deferred Procedure Call)  800  during interrupt processing, or from the SystemTickTimer( ) function  900  during receive polling when the receive interrupt is disabled. When this function executes, it will process data until there is no longer data to be processed or until the throttling code described in steps  1005  and  1006  disables the bReceivePollingFlag. 
     As shown in FIG. 11, the NAI Sniffer Adapter Software Driver  14  creates a function known as InterruptEnableDisableThreshold( ) denoted by step  1100 . This function will determine if the receive interrupt shall be enabled or disabled dependent upon the total number of packets received during the time period of the last system tick (as previously defined is typically 10 ms). The algorithm of steps  1101  through  1106 , describes a method to reduce the total number of interrupt notifications that will occur. This states that if the total number of packets received during a single NT system tick exceeds a specified threshold, then receive interrupt notification will be disabled. When the number of packets received during a single NT system tick falls below another threshold, then the receive interrupt notification will be re-enabled. This reduces interrupt overhead experienced during high network load. 
     Although various embodiments of the invention have been shown and described they are not meant to be limiting. Those of ordinary skill in the art may recognize certain modifications to these embodiments, which modifications are meant to be covered by the spirit and scope of the appended claims.