US20040236880A1 - Dynamically self-adjusting polling mechanism - Google Patents
Dynamically self-adjusting polling mechanism Download PDFInfo
- Publication number
- US20040236880A1 US20040236880A1 US10/440,681 US44068103A US2004236880A1 US 20040236880 A1 US20040236880 A1 US 20040236880A1 US 44068103 A US44068103 A US 44068103A US 2004236880 A1 US2004236880 A1 US 2004236880A1
- Authority
- US
- United States
- Prior art keywords
- buffer pool
- messages
- recited
- service application
- polling
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0766—Error or fault reporting or storing
- G06F11/0787—Storage of error reports, e.g. persistent data storage, storage using memory protection
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0745—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in an input/output transactions management context
Definitions
- the present invention relates, generally, to the logging of messages from an adapter card in a host computer and, in one embodiment, to a system and method for dynamically adjusting the rate of message buffer processing in response to message buffer consumption to reduce the probability of message buffer overruns, while at the same time preserving memory and lowering processor utilization.
- Host bus adapters are input/output (I/O) adapters that connect a host computer's bus and an outside network such as a Fibre Channel loop. HBAs manage the transfer of information between the bus and the outside network. HBAs are typically implemented in circuit cards that can be plugged into the backplane of the host computer. For example, a HBA can be inserted into a connector which interfaces to the Peripheral Component Interconnect (PCI) bus of a host computer to enable the host computer to communicate with a storage area network (SAN) using, for example, fibre channel or Internet Small Computer System Interface (iSCSI) protocols.
- PCI Peripheral Component Interconnect
- SAN storage area network
- iSCSI Internet Small Computer System Interface
- status, debug, error or other types of messages may be generated by firmware in the HBA.
- status messages may be generated when its state changes, or a sequence of detailed debug messages may be generated as the firmware attempts to connect to a target device.
- Each step of the connection process can be monitored if the firmware is configured for that type of message logging.
- Error messages may also be generated when a connection to a storage device has failed or has terminated unexpectedly.
- HBAs provide a message logging capability for storing certain messages at the host computer. Without this capability, messages generated in the HBA could not be stored in the host computer disk file for subsequent retrieval by an operator.
- the number of messages logged by the host computer depends on a predetermined logging level. In other words, although many messages may be generated by the HBA, only certain types of messages are typically logged.
- Another message logging restriction imposed by the operating system is related to the allocation of memory for storing messages.
- Microsoft's Windows® operating system only allows a device driver to allocate memory for itself at system startup. At that time, the device driver must estimate or otherwise request a memory allocation, and thereafter is stuck with this initial allocation. Microsoft also discourages developers of device drivers not to waste memory by allocating too much memory at startup. With the memory size restricted, if the HBA attempts to log too many messages, buffer overruns will occur and messages will be lost.
- Embodiments of the present invention are directed to a system and method for efficiently log messages from a circuit card such as a HBA to a host computer which minimizes the number of messages lost while preserving system bandwidth to the maximum extent possible by avoiding unnecessary polling.
- embodiments of the present invention help to prevent the loss of event messages due to message buffer overruns in situations where the number of available message buffers is fixed and the rate of generation of log messages being placed into the message buffers cannot be controlled.
- embodiments of the present invention employ a separate set of message buffers for storing vendor-specific messages and a separate service application for polling and storing vendor-specific messages.
- a vendor-specific buffer pool is loaded with log messages by firmware in an adapter and emptied by a service application within a host computer.
- the vendor-specific buffer pool is allocated to a device driver associated with the adapter upon system startup, and comprises part of the memory in the host computer.
- the device driver resides on the host computer, and runs in kernel space (privileged memory space allocated by the host computer's operating system) in the host computer's main memory.
- the service application periodically polls the device driver for messages.
- the device driver responds with the number of messages stored in the buffer pool and the total number of buffers in the buffer pool.
- the service application then issues “get next message” requests to the device driver, which replies by sending the queued messages to the service application. Once the buffer pool has been emptied, the service application writes the messages to a disk file.
- the service application then computes a percent utilization of the buffer pool, and if the percent utilization exceeds a predetermined threshold, an algorithm is employed for increasing the polling frequency. If the percent utilization is below the threshold, an algorithm is employed for decreasing the polling frequency. In general, the algorithms cause the polling frequency to rise quickly as buffer utilization increases, but fall slowly as utilization decreases to ensure that buffer overruns do not occur during secondary activity peaks of message bursts.
- FIG. 1 is an exemplary block diagram illustrating a vendor-specific buffer pool which is loaded by firmware in an adapter and emptied by a service application within a host computer according to embodiments of the present invention.
- Embodiments of the present invention efficiently log messages from a circuit card such as a HBA to a host computer, minimizing the number of messages lost while preserving system bandwidth to the maximum extent possible by avoiding unnecessary polling.
- embodiments of the present invention help to prevent the loss of event messages due to message buffer overruns in situations where the number of available message buffers is fixed and the rate of generation of log messages being placed into the message buffers cannot be controlled.
- embodiments of the present invention employ a separate set of message buffers for storing vendor-specific messages and a separate service application for polling and storing vendor-specific messages. It should be understood that the vendor-specific event logs utilized by embodiments of the present invention serve a different function and therefore can operate in parallel with operating system event logs such as Microsoft's Windows® System Event Log.
- FIG. 1 is an exemplary block diagram illustrating a vendor-specific buffer pool 100 , which is loaded by firmware 104 in adapter 106 and emptied by a service application 108 within a host computer 102 according to embodiments of the present invention.
- the adapter 106 is a HBA implementing iSCSI.
- the vendor-specific buffer pool 100 is allocated to a device driver 114 (e.g. a mini-port driver) associated with the adapter 106 upon system startup, and comprises part of the memory in the host computer 102 .
- the device driver 114 resides on the host computer 102 , and runs in kernel space 110 (privileged memory space allocated by the host computer's operating system) in the host computer's main memory.
- the service application 108 periodically polls the vendor-specific buffer pool 100 for messages.
- the firmware 104 is designed to generate messages for events that affect the network managed by the adapter 108 .
- a message may be generated if a link to a storage device on the network has gone down or is having problems. Note that such events would not be recognized by Microsoft's system event log, and therefore could not be logged with the host computer using Microsoft's System Event Log.
- the polling system employed by embodiments of the present invention is tailored to adapter cards, the polling system is able to log messages specific to the adapter 106 and is generally able to provide more detail than an operating system's system event log.
- Messages are generated by the firmware 104 in the adapter 106 when the firmware detects state changes. Detailed messages such as status, debug and error messages or other types of messages are possible, as are a series of messages generated as the firmware attempts to connect to a target. However, not all messages are logged.
- Log messages 112 are selected by the firmware 104 according to a logging level that is configurable within the firmware 104 . In preferred embodiments, log messages 112 are generated when a connection managed by the adapter 106 (e.g.
- firmware 104 When the firmware 104 generates a log message 112 (a Log Entry event), it sends a message containing details of the event to the device driver 114 (e.g. a mini-port driver).
- the device driver 114 e.g. a mini-port driver.
- the device driver 114 stores this log message 112 in a buffer in a fixed-size buffer pool 100 until the buffer is processed by a service application 108 in user space.
- the device driver 114 may be automatically installed from the adapter 106 into the host computer 102 by a plug-and-play mechanism in the OS when the system is first powered up.
- the size of the fixed buffer pool 100 associated with the device driver 114 is also established at system startup.
- the device driver 114 allocates a fixed number of vendor-specific buffers 100 for temporarily storing log messages 112 . Once allocated, the number of vendor-specific buffers 100 reserved for the adapter 106 cannot be increased or decreased.
- the number of buffers allocated will be enough to store all of the log messages 112 that may be produced during each polling period. This encourages the allocation of a greater number of buffers to ensure that buffer overrun does not occur. However, because unused buffers represent wasted memory, it is also desirable to keep the number of buffers to a minimum.
- the log messages 112 can be transferred to a disk file 116 within or connected to the host computer 116 .
- the device driver 114 cannot notify the service application 108 that a log message 112 has arrived and is being stored in one of the buffers in the buffer pool 100 . Instead, the service application 108 must periodically poll the device driver 114 to determine if there are any log messages available. Note that the service application 108 may be installed by an installation program supplied by the vendor of the adapter 106 .
- buffer utilization should approach 100%. That is, polling should occur just often enough that most of the buffers are full each time the buffers are polled.
- the Log Entry events that produce the log messages stored in the buffers do not occur at regular, predictable intervals. In fact, there could be long periods during which no log messages are produced and other periods where a great number of events occur producing a large amount of log messages in a short period of time. Thus it is not possible to determine a single ideal polling period.
- the adapter 106 may, at times, actually generate log messages 112 at a rate faster than the service application 108 can poll and remove messages 120 from the buffer pool 100 . Because there are a fixed number of buffers in the buffer pool 100 , if this situation should occur, the buffer pool 100 may become completely full, and further log messages 112 will be dropped. Unlike networking systems, which tag incoming messages with a sequence number and can therefore identify and retransmit lost messages, log messages 112 in the system of FIG. 1 that encounter a full buffer pool 100 will be lost.
- log messages 104 are configured to be limited to “event” messages, created during catastrophic or leading up to catastrophic events.
- the system may operate fine for weeks or months without any log messages 112 , and it would be a waste of system resources to have frequent polling 118 when no log messages 112 are being received by the buffer pool 100 .
- event messages are typically received, in bursts, over a short period of time.
- embodiments of the present invention dynamically change the rate at which the service application 108 polls the buffer pool 100 .
- the polling mechanism (service application 108 ) dynamically self-adjusts its polling frequency in response to system behavior.
- embodiments of the present invention dynamically adjust the rate of buffer processing in response to the rate of buffer consumption to reduce the probability of buffer overrun while at the same time preserving memory and lowering processor utilization.
- the service application 108 monitors the percent utilization of the buffer pool 100 . It does this by examining the number of buffers used by the device driver 114 to store log messages 112 during each polling period, and comparing it to the total number of buffers in the fixed buffer pool 100 . If the percent utilization meets or exceeds a predetermined threshold, then the polling frequency is increased. This allows the number of polling operations to be kept to the minimum needed to prevent buffer overruns.
- the polling frequency is increased. For example, if the buffer pool is comprised of 50 buffers, and in one polling period 25 messages are buffered, the 50% threshold will have been reached and the service application 108 will increase its polling rate (i.e. decrease the time between polls). In a preferred embodiment, the polling rate increase will be 50%, so the next polling period will be two thirds of the current polling period. The next time the buffer pool 100 is polled, the percent utilization of the buffer pool 100 will hopefully have fallen below the 50% threshold.
- an attempt is made to maintain a buffer utilization of approximately 50%.
- An underlying assumption of this polling algorithm is that when the number of log messages 112 increases, they increase at a relatively constant rate. In other words, in two consecutive polling time periods, roughly the same number of log messages 112 would be sent from the adapter 106 to the buffer pool 100 .
- the percent utilization of the buffer pool 100 is determined at the time of polling.
- the device driver 114 is queried for the number of messages stored in the buffer pool 100 .
- the device driver 114 returns a two-part reply 122 containing the number of log messages 112 being stored by the buffer pool 100 and the total number of buffers in the buffer pool 100 . From these answers, the service application 108 can determine how many times it must send a “get next message” command 124 to empty the buffers.
- the service application 108 repeatedly sends “get next message” requests 124 to the device driver 114 , which returns messages 120 containing the log messages 112 stored in the buffer pool 100 .
- the service application 108 maintains a count in accordance with the known number of log messages in the buffer pool 100 until all messages have been received.
- the messages 120 are typically stored in internal buffers(not shown in FIG. 1) when received by the service application 108 , and when they are all received, they are written to the disk file 116 in a single disk write command.
- the single disk write command is faster and requires less CPU involvement than a series of individual writes to the disk file 116 .
- the buffer pool's percent utilization is then calculated from the two-part reply 122 received from the device driver 114 in response to a poll 118 from the service application 108 . If the percent utilization is at or above the desired threshold, then the next polling period is determined using a formula for increasing the polling rate. If the percent utilization is below the desired threshold, then the next polling period is determined using a formula for decreasing the polling rate.
- the time of the next poll can be calculated using the following formula:
- ⁇ : B a the ⁇ ⁇ number ⁇ ⁇ of ⁇ ⁇ buffers ⁇ ⁇ available
- B u the ⁇ ⁇ number ⁇ ⁇ of ⁇ ⁇ buffers ⁇ ⁇ used ⁇ ⁇ during ⁇ the ⁇ ⁇ last ⁇ ⁇ polling ⁇ ⁇ period
- P the ⁇ ⁇ desired ⁇ ⁇ percentage ⁇ ⁇ of ⁇ ⁇ buffer ⁇ ⁇ utilization
- T c the ⁇ ⁇ current ⁇ ⁇ polling ⁇ ⁇ period ⁇ ⁇ length
- T a the ⁇ ⁇ adjusted ⁇ ⁇ polling ⁇ ⁇ period ⁇ ⁇ length
- the service application 108 In between polls, the service application 108 “goes to sleep,” and is inactive until the operating system of the host computer 102 invokes the service application 108 at the next polling period. To enter the sleep mode, the service application 108 may issue a call the operating system containing a sleep duration argument. In one embodiment, the sleep duration argument is in whole milliseconds.
- the thresholds, algorithms and formula specified above are only exemplary, and that other thresholds, algorithms and formulae could be used and fall within the scope of the invention.
- the 50% percent utilization threshold and/or the 50% polling rate increase could be different.
- the service application may poll at a predetermined maximum polling rate until the percent utilization falls below 50%.
- the service application may poll at a predetermined maximum polling rate until the percent utilization falls below 50%. This would be useful for systems characterized by sudden, high levels of message activity. This increase would be made regardless of buffer utilization levels.
- the polling frequency may be increased by a fixed amount (not a fixed percentage). This could be used in systems where the message activity increased at a steady or predictable rate. The preferred formula depends on the characteristics of message arrivals in the system.
- a configuration utility may be supplied with the adapter to enable users to specify the types of messages to be logged, the name of the log file, the maximum period between polls, the percent utilization thresholds, the polling change rates, and other parameters.
- the polling frequency is not immediately slowed down once the percent utilization falls below the designated threshold. For example, if the target percent utilization is 50% and the computed percent utilization is below 50%, then in a preferred embodiment, the service application 108 will not slow down the polling rate until it has detected four consecutive polling periods of less than 25% buffer utilization, at which time the polling frequency may be decreased by 10%. If four additional consecutive polling periods of less than 25% buffer utilization are detected, the polling frequency is again decreased by 10%.
- the polling rate is set to the minimum frequency (slowest polling rate).
- the idea behind this approach is to maintain the rate of polling until a period of message inactivity is reached and then instantly reduce the polling frequency in order to preserve CPU and driver bandwidth. This would be useful in systems characterized by message activity that suddenly stops and then has long periods of inactivity (relative to the CPU's view of time).
- the polling frequency is decreased by a set amount until the minimum frequency is reached. Depending on the amount of decrease, the overall decrease rate could be slow or rapid. This would be useful for systems where the message activity tapered off at a fairly fixed rate.
- the polling frequency rises quickly as buffer utilization increases, it falls slowly as utilization decreases which further helps to insure that buffer overruns do not occur during secondary activity peaks.
- the algorithm for decreasing the polling frequency also has a predetermined floor below which the polling frequency is not allowed to decrease. This purpose of this floor is to insure that the frequency does not decrease to the point where polling effectively stops. This floor, once set, resides in permanent memory so that it is remembered upon startup.
- the device driver 100 in the host computer 102 is initialized.
- a fixed number of buffers comprising a buffer pool 100 are allocated to the device driver (e.g. 36 buffers).
- the adapter card 106 and firmware 104 are initialized to indicate which type of events are to be logged (e.g. event messages only).
- the initial polling period and desired percent utilization are set to default and/or preselected values (e.g. 10 ms and 50%, respectively), and the host computer 102 then begins to execute the service application 108 .
- the service application 108 polls the device driver 114 using message 118 , asking for the number of log messages currently being stored in the buffer pool 100 , and how many total buffers are in the buffer pool 100 .
- the device driver 114 responds with a reply message 122 containing information on the number of log messages and the total number of buffers (e.g. 18 log messages and 36 buffers.
- the service application 108 then transmits a “get next message” request 124 to the device driver 114 , and the device driver 114 responds with the next message 120 in the queue of buffers. This process will loop until all messages have been cleared from the buffers.
- the service application 108 maintains a count in accordance with the known number of log messages in the buffer pool 100 until all messages have been received.
- the log messages are then written in a single write command to the disk file 116 .
- the service application 108 After saving the messages to the disk file 116 , the service application 108 computes the percent utilization of the buffer pool 100 , determines whether the formula for increasing or decreasing the polling rate should be used, and then computes the next polling period using the appropriate formula provided above. In the present example, it computes (36/18 ⁇ 0.5 ⁇ 10 ms), so the next polling period is computed to be 10 ms later. The service application 108 then goes to sleep for 10 ms.
- the buffer pool 100 receives many log messages 112 , filling up the buffers until all 36 buffers in the buffer pool 100 are full.
- the service application 108 again sends poll 118 to the device driver 114 , and the device driver 114 replies at 122 , indicating that it has 36 messages and 36 buffers.
- the adapter 106 gets more messages than there are buffers, once the buffers are full then subsequent log messages will be lost.
- the service application 108 polls the device driver 114 , the reply will contain an answer of 0 log messages stored, and 36 total buffers in the buffer pool 100 .
- the service application 108 determines which formula to use. In this case, because there are no messages, the service application 108 uses the formula for decreasing the polling rate described above. Because this is the first polling period in which the percent utilization is ⁇ 25%, the polling rate is not changed. The system service maintains a count indicating that this is the first polling period with a buffer percent utilization of under 25%. However, if this happens for four consecutive polling periods, then after the fourth polling period, the polling rate will be decreased by 10%.
- the polling rate is decreased by 10%, it will not decrease again until four more consecutive polling periods have elapsed, each with a buffer percent utilization of less than 25%.
- the count of consecutive periods under 25% utilization is not reset when the polling rate is decreased by 10%, so if the next polling period still has a percent utilization of under 25%, the polling rate is again decreased by 10%.
Abstract
Description
- 1. Field of the Invention
- The present invention relates, generally, to the logging of messages from an adapter card in a host computer and, in one embodiment, to a system and method for dynamically adjusting the rate of message buffer processing in response to message buffer consumption to reduce the probability of message buffer overruns, while at the same time preserving memory and lowering processor utilization.
- 2. Description of Related Art
- Host bus adapters (HBAs) are input/output (I/O) adapters that connect a host computer's bus and an outside network such as a Fibre Channel loop. HBAs manage the transfer of information between the bus and the outside network. HBAs are typically implemented in circuit cards that can be plugged into the backplane of the host computer. For example, a HBA can be inserted into a connector which interfaces to the Peripheral Component Interconnect (PCI) bus of a host computer to enable the host computer to communicate with a storage area network (SAN) using, for example, fibre channel or Internet Small Computer System Interface (iSCSI) protocols.
- During the course of HBA operation, status, debug, error or other types of messages may be generated by firmware in the HBA. For example, status messages may be generated when its state changes, or a sequence of detailed debug messages may be generated as the firmware attempts to connect to a target device. Each step of the connection process can be monitored if the firmware is configured for that type of message logging. Error messages may also be generated when a connection to a storage device has failed or has terminated unexpectedly.
- It is often beneficial for the host computer to log (store) these messages for subsequent troubleshooting, for example. Thus, some HBAs provide a message logging capability for storing certain messages at the host computer. Without this capability, messages generated in the HBA could not be stored in the host computer disk file for subsequent retrieval by an operator. The number of messages logged by the host computer depends on a predetermined logging level. In other words, although many messages may be generated by the HBA, only certain types of messages are typically logged.
- Although in theory all messages generated by the HBA could be logged, in practice this is not the case. Restrictions on message logging may be imposed by the operating system of the host computer. For example, Microsoft's Windows® operating system provides a system event log for logging messages from a mini-port driver for an adapter card, but Microsoft only provides for the logging of a prescribed set of events (messages) that affect the host computer. The Windows system event log records events that are of interest to the Windows® Operating System, such as the successful startup of a driver, the failure of a driver to start, or a fatal condition encountered by a driver. However, Microsoft does not provide for the logging of vendor-specific events (i.e. events specific to a HBA card).
- In computers employing a system event log, when the driver for a HBA recognizes an event that can be logged, the driver makes a call to the operating system (OS), telling the OS to log the message for the driver. The messages must correspond to a predefined event number assigned by Microsoft. The OS writes the messages to a disk file at its convenience, because these messages are often created during startup when the disk drive may not be available (i.e., still spinning up to speed).
- Another message logging restriction imposed by the operating system is related to the allocation of memory for storing messages. For example, Microsoft's Windows® operating system only allows a device driver to allocate memory for itself at system startup. At that time, the device driver must estimate or otherwise request a memory allocation, and thereafter is stuck with this initial allocation. Microsoft also discourages developers of device drivers not to waste memory by allocating too much memory at startup. With the memory size restricted, if the HBA attempts to log too many messages, buffer overruns will occur and messages will be lost.
- Thus, a need exists for a system which is able to efficiently log messages from a HBA and minimize the number of messages lost, while avoiding the limitations imposed by operating systems such as Microsoft's Windows® operating system.
- Embodiments of the present invention are directed to a system and method for efficiently log messages from a circuit card such as a HBA to a host computer which minimizes the number of messages lost while preserving system bandwidth to the maximum extent possible by avoiding unnecessary polling. In particular, embodiments of the present invention help to prevent the loss of event messages due to message buffer overruns in situations where the number of available message buffers is fixed and the rate of generation of log messages being placed into the message buffers cannot be controlled. To avoid possible restrictions imposed by system event logs managed by the operating system of the host computer, embodiments of the present invention employ a separate set of message buffers for storing vendor-specific messages and a separate service application for polling and storing vendor-specific messages.
- In one embodiment of the present invention, a vendor-specific buffer pool is loaded with log messages by firmware in an adapter and emptied by a service application within a host computer. The vendor-specific buffer pool is allocated to a device driver associated with the adapter upon system startup, and comprises part of the memory in the host computer. The device driver resides on the host computer, and runs in kernel space (privileged memory space allocated by the host computer's operating system) in the host computer's main memory. The service application periodically polls the device driver for messages. The device driver responds with the number of messages stored in the buffer pool and the total number of buffers in the buffer pool. The service application then issues “get next message” requests to the device driver, which replies by sending the queued messages to the service application. Once the buffer pool has been emptied, the service application writes the messages to a disk file.
- The service application then computes a percent utilization of the buffer pool, and if the percent utilization exceeds a predetermined threshold, an algorithm is employed for increasing the polling frequency. If the percent utilization is below the threshold, an algorithm is employed for decreasing the polling frequency. In general, the algorithms cause the polling frequency to rise quickly as buffer utilization increases, but fall slowly as utilization decreases to ensure that buffer overruns do not occur during secondary activity peaks of message bursts.
- FIG. 1 is an exemplary block diagram illustrating a vendor-specific buffer pool which is loaded by firmware in an adapter and emptied by a service application within a host computer according to embodiments of the present invention.
- In the following description of preferred embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration specific embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the preferred embodiments of the present invention. It should also be noted that although embodiments of the present invention are primarily described herein in terms of logging messages from HBAs to a host computer for purposes of illustration and discussion only, embodiments of the present invention include the logging of messages from other add-on adapters or circuit cards.
- Embodiments of the present invention efficiently log messages from a circuit card such as a HBA to a host computer, minimizing the number of messages lost while preserving system bandwidth to the maximum extent possible by avoiding unnecessary polling. In particular, embodiments of the present invention help to prevent the loss of event messages due to message buffer overruns in situations where the number of available message buffers is fixed and the rate of generation of log messages being placed into the message buffers cannot be controlled. To avoid possible restrictions imposed by system event logs managed by the operating system of the host computer, embodiments of the present invention employ a separate set of message buffers for storing vendor-specific messages and a separate service application for polling and storing vendor-specific messages. It should be understood that the vendor-specific event logs utilized by embodiments of the present invention serve a different function and therefore can operate in parallel with operating system event logs such as Microsoft's Windows® System Event Log.
- FIG. 1 is an exemplary block diagram illustrating a vendor-
specific buffer pool 100, which is loaded byfirmware 104 inadapter 106 and emptied by aservice application 108 within ahost computer 102 according to embodiments of the present invention. In one embodiment, theadapter 106 is a HBA implementing iSCSI. The vendor-specific buffer pool 100 is allocated to a device driver 114 (e.g. a mini-port driver) associated with theadapter 106 upon system startup, and comprises part of the memory in thehost computer 102. Thedevice driver 114 resides on thehost computer 102, and runs in kernel space 110 (privileged memory space allocated by the host computer's operating system) in the host computer's main memory. Theservice application 108 periodically polls the vendor-specific buffer pool 100 for messages. - The
firmware 104 is designed to generate messages for events that affect the network managed by theadapter 108. For example, a message may be generated if a link to a storage device on the network has gone down or is having problems. Note that such events would not be recognized by Microsoft's system event log, and therefore could not be logged with the host computer using Microsoft's System Event Log. - In general, because the polling system employed by embodiments of the present invention is tailored to adapter cards, the polling system is able to log messages specific to the
adapter 106 and is generally able to provide more detail than an operating system's system event log. Messages are generated by thefirmware 104 in theadapter 106 when the firmware detects state changes. Detailed messages such as status, debug and error messages or other types of messages are possible, as are a series of messages generated as the firmware attempts to connect to a target. However, not all messages are logged. Logmessages 112 are selected by thefirmware 104 according to a logging level that is configurable within thefirmware 104. In preferred embodiments, logmessages 112 are generated when a connection managed by the adapter 106 (e.g. a connection to a storage device) has failed. When thefirmware 104 generates a log message 112 (a Log Entry event), it sends a message containing details of the event to the device driver 114 (e.g. a mini-port driver). It should be noted that although firmware is described above, in alternative embodiments the firmware may be replaced by the hardware or software equivalent, referred to generally herein as logic. - The
device driver 114 stores thislog message 112 in a buffer in a fixed-size buffer pool 100 until the buffer is processed by aservice application 108 in user space. Thedevice driver 114 may be automatically installed from theadapter 106 into thehost computer 102 by a plug-and-play mechanism in the OS when the system is first powered up. The size of the fixedbuffer pool 100 associated with thedevice driver 114 is also established at system startup. During the initialization sequence for thedevice driver 114 at system startup, thedevice driver 114 allocates a fixed number of vendor-specific buffers 100 for temporarily storinglog messages 112. Once allocated, the number of vendor-specific buffers 100 reserved for theadapter 106 cannot be increased or decreased. Ideally the number of buffers allocated will be enough to store all of thelog messages 112 that may be produced during each polling period. This encourages the allocation of a greater number of buffers to ensure that buffer overrun does not occur. However, because unused buffers represent wasted memory, it is also desirable to keep the number of buffers to a minimum. - Ideally, as
log messages 112 temporarily accumulate in thebuffer pool 100, the log messages can be transferred to adisk file 116 within or connected to thehost computer 116. However, because of operating system restrictions, thedevice driver 114 cannot notify theservice application 108 that alog message 112 has arrived and is being stored in one of the buffers in thebuffer pool 100. Instead, theservice application 108 must periodically poll thedevice driver 114 to determine if there are any log messages available. Note that theservice application 108 may be installed by an installation program supplied by the vendor of theadapter 106. - Given a fixed number of buffers, in order to minimize the CPU bandwidth used in polling, buffer utilization should approach 100%. That is, polling should occur just often enough that most of the buffers are full each time the buffers are polled. However, the Log Entry events that produce the log messages stored in the buffers do not occur at regular, predictable intervals. In fact, there could be long periods during which no log messages are produced and other periods where a great number of events occur producing a large amount of log messages in a short period of time. Thus it is not possible to determine a single ideal polling period.
- As a result, it is up to the
service application 108 in user space to poll thedevice driver 114 frequently enough so that it will not run out of buffers and that the number of buffers in thebuffer pool 100 can be kept to a minimum. However, polling is expensive in terms of CPU bandwidth if it is performed too often. Excessive polling can also have a negative impact on the device driver's throughput. It is therefore highly desirable not to poll any more than necessary, and selecting the polling period becomes a balancing act between preventing buffer overrun and wasting CPU and driver bandwidth. - Nevertheless, despite the careful selection of the size of the fixed buffer pool10, the
adapter 106 may, at times, actually generatelog messages 112 at a rate faster than theservice application 108 can poll and removemessages 120 from thebuffer pool 100. Because there are a fixed number of buffers in thebuffer pool 100, if this situation should occur, thebuffer pool 100 may become completely full, andfurther log messages 112 will be dropped. Unlike networking systems, which tag incoming messages with a sequence number and can therefore identify and retransmit lost messages, logmessages 112 in the system of FIG. 1 that encounter afull buffer pool 100 will be lost. - One solution would be to have the
service application 108 poll thebuffer pool 100 more often. However, frequent polling consumes CPU horsepower and bandwidth and may unnecessarily degrade system performance due to the nature of thelog messages 112. Typically, logmessages 104 are configured to be limited to “event” messages, created during catastrophic or leading up to catastrophic events. Thus, the system may operate fine for weeks or months without anylog messages 112, and it would be a waste of system resources to havefrequent polling 118 when nolog messages 112 are being received by thebuffer pool 100. However, when something catastrophic does occur, many event messages are typically received, in bursts, over a short period of time. - Thus, embodiments of the present invention dynamically change the rate at which the
service application 108 polls thebuffer pool 100. In other words, the polling mechanism (service application 108) dynamically self-adjusts its polling frequency in response to system behavior. In particular, embodiments of the present invention dynamically adjust the rate of buffer processing in response to the rate of buffer consumption to reduce the probability of buffer overrun while at the same time preserving memory and lowering processor utilization. - To accomplish this goal, the
service application 108 monitors the percent utilization of thebuffer pool 100. It does this by examining the number of buffers used by thedevice driver 114 to storelog messages 112 during each polling period, and comparing it to the total number of buffers in the fixedbuffer pool 100. If the percent utilization meets or exceeds a predetermined threshold, then the polling frequency is increased. This allows the number of polling operations to be kept to the minimum needed to prevent buffer overruns. - For example, if 50% utilization of the buffer pool is selected as the desired threshold, then when the
service application 108 detects that one-half or more of the number of buffers in thebuffer pool 100 are filled with alog message 112, the polling frequency is increased. For example, if the buffer pool is comprised of 50 buffers, and in one polling period 25 messages are buffered, the 50% threshold will have been reached and theservice application 108 will increase its polling rate (i.e. decrease the time between polls). In a preferred embodiment, the polling rate increase will be 50%, so the next polling period will be two thirds of the current polling period. The next time thebuffer pool 100 is polled, the percent utilization of thebuffer pool 100 will hopefully have fallen below the 50% threshold. Thus, in this embodiment, an attempt is made to maintain a buffer utilization of approximately 50%. An underlying assumption of this polling algorithm is that when the number oflog messages 112 increases, they increase at a relatively constant rate. In other words, in two consecutive polling time periods, roughly the same number oflog messages 112 would be sent from theadapter 106 to thebuffer pool 100. - The percent utilization of the
buffer pool 100 is determined at the time of polling. During apoll 118, thedevice driver 114 is queried for the number of messages stored in thebuffer pool 100. Thedevice driver 114 returns a two-part reply 122 containing the number oflog messages 112 being stored by thebuffer pool 100 and the total number of buffers in thebuffer pool 100. From these answers, theservice application 108 can determine how many times it must send a “get next message”command 124 to empty the buffers. - Once the number of messages stored in the
buffer pool 100 is known, theservice application 108 repeatedly sends “get next message” requests 124 to thedevice driver 114, which returnsmessages 120 containing thelog messages 112 stored in thebuffer pool 100. Theservice application 108 maintains a count in accordance with the known number of log messages in thebuffer pool 100 until all messages have been received. Themessages 120 are typically stored in internal buffers(not shown in FIG. 1) when received by theservice application 108, and when they are all received, they are written to thedisk file 116 in a single disk write command. The single disk write command is faster and requires less CPU involvement than a series of individual writes to thedisk file 116. - In one embodiment of the present invention, after the
messages 120 are received by theservice application 108 and thebuffer pool 100 is emptied, the buffer pool's percent utilization is then calculated from the two-part reply 122 received from thedevice driver 114 in response to apoll 118 from theservice application 108. If the percent utilization is at or above the desired threshold, then the next polling period is determined using a formula for increasing the polling rate. If the percent utilization is below the desired threshold, then the next polling period is determined using a formula for decreasing the polling rate. For example, if the target buffer pool percent utilization is 50% and the computed percent utilization is at or above 50%, then the time of the next poll can be calculated using the following formula: - Although not shown in the above formula, as a matter of practicality embodiments of the present invention limit the polling period to some predetermined ceiling rate, such as the smallest period easily obtained by user space (non-device driver) code under the Windows operating system.
- In between polls, the
service application 108 “goes to sleep,” and is inactive until the operating system of thehost computer 102 invokes theservice application 108 at the next polling period. To enter the sleep mode, theservice application 108 may issue a call the operating system containing a sleep duration argument. In one embodiment, the sleep duration argument is in whole milliseconds. - It should be understood that the thresholds, algorithms and formula specified above are only exemplary, and that other thresholds, algorithms and formulae could be used and fall within the scope of the invention. For example, the 50% percent utilization threshold and/or the 50% polling rate increase could be different. In one particular example, once a 50% percent buffer pool utilization is reached, the service application may poll at a predetermined maximum polling rate until the percent utilization falls below 50%. In another example, once a received log message is detected, the service application may poll at a predetermined maximum polling rate until the percent utilization falls below 50%. This would be useful for systems characterized by sudden, high levels of message activity. This increase would be made regardless of buffer utilization levels. In another embodiment, each time the buffer utilization is above a set threshold, the polling frequency may be increased by a fixed amount (not a fixed percentage). This could be used in systems where the message activity increased at a steady or predictable rate. The preferred formula depends on the characteristics of message arrivals in the system. In one embodiment of the present invention, a configuration utility may be supplied with the adapter to enable users to specify the types of messages to be logged, the name of the log file, the maximum period between polls, the percent utilization thresholds, the polling change rates, and other parameters.
- As described above, event messages tend to occur in multiple bursts followed by long periods of inactivity. Because of this, in preferred embodiments of the present invention, a different algorithm is used to decrease the polling frequency as buffer utilization decreases. Generally, the polling rate is not immediately slowed down once the percent utilization falls below the designated threshold. For example, if the target percent utilization is 50% and the computed percent utilization is below 50%, then in a preferred embodiment, the
service application 108 will not slow down the polling rate until it has detected four consecutive polling periods of less than 25% buffer utilization, at which time the polling frequency may be decreased by 10%. If four additional consecutive polling periods of less than 25% buffer utilization are detected, the polling frequency is again decreased by 10%. - Without such a cautious approach to slowing down the polling rate, the
service application 108 could encounter a period of inactivity between event bursts and slow down the polling rate, only to discover at the next polling period that another burst oflog messages 112 had occurred, resulting in buffer overruns. The algorithm presented above attempts to minimize these buffer overruns by anticipating bursts and maintaining a high polling frequency throughout the bursts. - Again, this algorithm and thresholds are only exemplary, and other algorithms and thresholds may be used within the scope of the present invention. For example, in one embodiment of the present invention, once a set amount of time has passed without any messages being received, the polling rate is set to the minimum frequency (slowest polling rate). The idea behind this approach is to maintain the rate of polling until a period of message inactivity is reached and then instantly reduce the polling frequency in order to preserve CPU and driver bandwidth. This would be useful in systems characterized by message activity that suddenly stops and then has long periods of inactivity (relative to the CPU's view of time). In another embodiment, each time a polling period occurs without any messages being received, the polling frequency is decreased by a set amount until the minimum frequency is reached. Depending on the amount of decrease, the overall decrease rate could be slow or rapid. This would be useful for systems where the message activity tapered off at a fairly fixed rate.
- Thus, while the polling frequency rises quickly as buffer utilization increases, it falls slowly as utilization decreases which further helps to insure that buffer overruns do not occur during secondary activity peaks. As with the algorithm for increasing the polling frequency, the algorithm for decreasing the polling frequency also has a predetermined floor below which the polling frequency is not allowed to decrease. This purpose of this floor is to insure that the frequency does not decrease to the point where polling effectively stops. This floor, once set, resides in permanent memory so that it is remembered upon startup.
- A step-by-step exemplary overview will now be provided with reference to FIG. 1. When the
host computer 102 is first powered up, thedevice driver 100 in thehost computer 102 is initialized. During initialization, a fixed number of buffers comprising abuffer pool 100 are allocated to the device driver (e.g. 36 buffers). In addition, theadapter card 106 andfirmware 104 are initialized to indicate which type of events are to be logged (e.g. event messages only). - In the
service application 108, the initial polling period and desired percent utilization are set to default and/or preselected values (e.g. 10 ms and 50%, respectively), and thehost computer 102 then begins to execute theservice application 108. After 10 ms, theservice application 108 polls thedevice driver 114 usingmessage 118, asking for the number of log messages currently being stored in thebuffer pool 100, and how many total buffers are in thebuffer pool 100. Thedevice driver 114 responds with areply message 122 containing information on the number of log messages and the total number of buffers (e.g. 18 log messages and 36 buffers. - The
service application 108 then transmits a “get next message”request 124 to thedevice driver 114, and thedevice driver 114 responds with thenext message 120 in the queue of buffers. This process will loop until all messages have been cleared from the buffers. Theservice application 108 maintains a count in accordance with the known number of log messages in thebuffer pool 100 until all messages have been received. The log messages are then written in a single write command to thedisk file 116. - After saving the messages to the
disk file 116, theservice application 108 computes the percent utilization of thebuffer pool 100, determines whether the formula for increasing or decreasing the polling rate should be used, and then computes the next polling period using the appropriate formula provided above. In the present example, it computes (36/18×0.5×10 ms), so the next polling period is computed to be 10 ms later. Theservice application 108 then goes to sleep for 10 ms. - For purposes of illustration, assume that during this sleep period, the
buffer pool 100 receivesmany log messages 112, filling up the buffers until all 36 buffers in thebuffer pool 100 are full. At the next polling period, theservice application 108 again sendspoll 118 to thedevice driver 114, and thedevice driver 114 replies at 122, indicating that it has 36 messages and 36 buffers. After repeated “get next message” requests, resulting in the 36 messages being received at the host computer and stored in the disk file, theservice application 108 computes the next polling time as (36/36×0.5×10 ms=5 ms), so the next polling period is 5 ms later. - If, within the next 5 ms period, the
adapter 106 gets more messages than there are buffers, once the buffers are full then subsequent log messages will be lost. - On the other hand, if, in the next 5 ms period, no
log messages 112 were received at thebuffer pool 100, then at the next polling period, when theservice application 108 polls thedevice driver 114, the reply will contain an answer of 0 log messages stored, and 36 total buffers in thebuffer pool 100. After computing the percent utilization, theservice application 108 determines which formula to use. In this case, because there are no messages, theservice application 108 uses the formula for decreasing the polling rate described above. Because this is the first polling period in which the percent utilization is <25%, the polling rate is not changed. The system service maintains a count indicating that this is the first polling period with a buffer percent utilization of under 25%. However, if this happens for four consecutive polling periods, then after the fourth polling period, the polling rate will be decreased by 10%. - In one embodiment of the present invention, once the polling rate is decreased by 10%, it will not decrease again until four more consecutive polling periods have elapsed, each with a buffer percent utilization of less than 25%. In another embodiment, the count of consecutive periods under 25% utilization is not reset when the polling rate is decreased by 10%, so if the next polling period still has a percent utilization of under 25%, the polling rate is again decreased by 10%.
- Although the present invention has been fully described in connection with embodiments thereof with reference to the accompanying drawings, it is to be noted that various changes and modifications will become apparent to those skilled in the art. Such changes and modifications are to be understood as being included within the scope of the present invention as defined by the appended claims.
Claims (47)
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/440,681 US6931460B2 (en) | 2003-05-19 | 2003-05-19 | Dynamically self-adjusting polling mechanism |
TW093112793A TWI245993B (en) | 2003-05-19 | 2004-05-06 | System and method for storing adapter card messages into a buffer pool in a host computer and periodically polling the buffer pool to retrieve the messages |
PCT/US2004/014217 WO2004104730A2 (en) | 2003-05-19 | 2004-05-07 | Dynamically self-adjusting polling mechanism |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/440,681 US6931460B2 (en) | 2003-05-19 | 2003-05-19 | Dynamically self-adjusting polling mechanism |
Publications (2)
Publication Number | Publication Date |
---|---|
US20040236880A1 true US20040236880A1 (en) | 2004-11-25 |
US6931460B2 US6931460B2 (en) | 2005-08-16 |
Family
ID=33449840
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/440,681 Expired - Lifetime US6931460B2 (en) | 2003-05-19 | 2003-05-19 | Dynamically self-adjusting polling mechanism |
Country Status (3)
Country | Link |
---|---|
US (1) | US6931460B2 (en) |
TW (1) | TWI245993B (en) |
WO (1) | WO2004104730A2 (en) |
Cited By (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050165983A1 (en) * | 2004-01-26 | 2005-07-28 | Samsung Electronics Co., Ltd. | System and method for processing data in kernel area by a user command |
US20050259748A1 (en) * | 2004-05-21 | 2005-11-24 | Christopher Payson | Buffer for driving display with asynchronous display engine |
US20060173971A1 (en) * | 2005-02-01 | 2006-08-03 | Russell Paul F | Adjusting timing between automatic, non-user-initiated pollings of server to download data therefrom |
US20060294182A1 (en) * | 2005-06-24 | 2006-12-28 | Brother Kogyo Kabushiki Kaisha | Service providing system, and client, server, and program for the same |
US20070294392A1 (en) * | 2006-06-20 | 2007-12-20 | International Business Machines Corporation | Apparatus, system, and method for intelligent polling support for websphere adapters based on the self-configuration characteristic of an autonomic computing model |
US20080189419A1 (en) * | 2007-02-02 | 2008-08-07 | David Andrew Girle | System and Method to Synchronize OSGi Bundle Inventories Between an OSGi Bundle Server and a Client |
US20080253393A1 (en) * | 2007-04-13 | 2008-10-16 | At&T Knowledge Ventures, L.P. | System and method for managing network traffic |
WO2011160712A1 (en) * | 2010-06-23 | 2011-12-29 | International Business Machines Corporation | Managing processing associated with hardware events |
US20130117465A1 (en) * | 2005-12-28 | 2013-05-09 | Solarflare Communications, Inc. | Processing received data |
US8458387B2 (en) | 2010-06-23 | 2013-06-04 | International Business Machines Corporation | Converting a message signaled interruption into an I/O adapter event notification to a guest operating system |
US8478922B2 (en) | 2010-06-23 | 2013-07-02 | International Business Machines Corporation | Controlling a rate at which adapter interruption requests are processed |
US8504754B2 (en) | 2010-06-23 | 2013-08-06 | International Business Machines Corporation | Identification of types of sources of adapter interruptions |
US8505032B2 (en) | 2010-06-23 | 2013-08-06 | International Business Machines Corporation | Operating system notification of actions to be taken responsive to adapter events |
US8549182B2 (en) | 2010-06-23 | 2013-10-01 | International Business Machines Corporation | Store/store block instructions for communicating with adapters |
US8566480B2 (en) | 2010-06-23 | 2013-10-22 | International Business Machines Corporation | Load instruction for communicating with adapters |
US8572635B2 (en) | 2010-06-23 | 2013-10-29 | International Business Machines Corporation | Converting a message signaled interruption into an I/O adapter event notification |
US8615645B2 (en) | 2010-06-23 | 2013-12-24 | International Business Machines Corporation | Controlling the selectively setting of operational parameters for an adapter |
US8621112B2 (en) | 2010-06-23 | 2013-12-31 | International Business Machines Corporation | Discovery by operating system of information relating to adapter functions accessible to the operating system |
US8626970B2 (en) | 2010-06-23 | 2014-01-07 | International Business Machines Corporation | Controlling access by a configuration to an adapter function |
US8631222B2 (en) | 2010-06-23 | 2014-01-14 | International Business Machines Corporation | Translation of input/output addresses to memory addresses |
US8639858B2 (en) | 2010-06-23 | 2014-01-28 | International Business Machines Corporation | Resizing address spaces concurrent to accessing the address spaces |
US8650335B2 (en) | 2010-06-23 | 2014-02-11 | International Business Machines Corporation | Measurement facility for adapter functions |
US8650337B2 (en) | 2010-06-23 | 2014-02-11 | International Business Machines Corporation | Runtime determination of translation formats for adapter functions |
US9195623B2 (en) | 2010-06-23 | 2015-11-24 | International Business Machines Corporation | Multiple address spaces per adapter with address translation |
US9213661B2 (en) | 2010-06-23 | 2015-12-15 | International Business Machines Corporation | Enable/disable adapters of a computing environment |
US9342352B2 (en) | 2010-06-23 | 2016-05-17 | International Business Machines Corporation | Guest access to address spaces of adapter |
US20160196365A1 (en) * | 2015-01-06 | 2016-07-07 | International Business Machines Corporation | Simulating a large network load |
US20190080334A1 (en) * | 2017-09-14 | 2019-03-14 | Bank Of America Corporation | Centralized compliance assessment tool |
US11074202B1 (en) * | 2020-02-26 | 2021-07-27 | Red Hat, Inc. | Efficient management of bus bandwidth for multiple drivers |
US11082354B2 (en) | 2019-06-12 | 2021-08-03 | Vmware, Inc. | Adaptive polling in software-defined networking (SDN) environments |
US11163628B2 (en) * | 2019-12-12 | 2021-11-02 | EMC IP Holding Company LLC | Method, device and computer program product for error management based on a utilization rate of an accelerator device |
US11252070B2 (en) * | 2018-10-09 | 2022-02-15 | Vmware, Inc. | Adaptive polling in software-defined networking (SDN) environments |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7457991B1 (en) * | 2002-12-03 | 2008-11-25 | Unisys Corporation | Method for scanning windows event logs on a cellular multi-processor (CMP) server |
US8121595B2 (en) * | 2004-06-02 | 2012-02-21 | Intel Corporation | Adaptive polling of wireless devices |
US9031568B2 (en) * | 2004-07-28 | 2015-05-12 | Broadcom Corporation | Quality-of-service (QoS)-based association with a new network using background network scanning |
US8286169B2 (en) * | 2005-06-17 | 2012-10-09 | Intel Corporation | Dynamic scheduling an interval for polling devices based on a current operational power mode in an extensible firmware interface architecture |
US20100302919A1 (en) * | 2005-10-27 | 2010-12-02 | Mediatek Inc. | Optical Recording Method and Apparatus |
US20070097817A1 (en) * | 2005-10-27 | 2007-05-03 | Mediatek Inc. | Method and system for recording data with data verifying process |
US20070260771A1 (en) * | 2006-04-10 | 2007-11-08 | Cheng-Hao Lee | Method of Reducing Clock Differential in a Data Processing System |
CN101378544B (en) * | 2007-08-31 | 2011-12-07 | 国际商业机器公司 | Method, device and system for polling information |
US9448839B2 (en) * | 2013-03-08 | 2016-09-20 | Oracle International Corporation | Backoff job queue polling mechanism |
US20140289428A1 (en) * | 2013-03-20 | 2014-09-25 | Microsoft Corporation | Dynamic Intervals for Synchronizing Data |
US9032119B2 (en) | 2013-07-25 | 2015-05-12 | Alcatel Lucent | Adaptive polling of information from a device |
US10534733B2 (en) * | 2018-04-26 | 2020-01-14 | EMC IP Holding Company LLC | Flexible I/O slot connections |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4598363A (en) * | 1983-07-07 | 1986-07-01 | At&T Bell Laboratories | Adaptive delayed polling of sensors |
US5566351A (en) * | 1994-06-20 | 1996-10-15 | International Business Machines Corporation | Adaptive polling system by generating sequence of polling signals whose magnitudes are functionally related to the occurrence of the busy signal |
US6049549A (en) * | 1997-08-14 | 2000-04-11 | University Of Massachusetts | Adaptive media control |
US6449663B1 (en) * | 1998-07-08 | 2002-09-10 | International Business Machines Corporation | Method and apparatus for adjusting an interval of polling a network printer based on changes in working status of the network printer |
US6467011B2 (en) * | 1999-03-19 | 2002-10-15 | Times N Systems, Inc. | Shared memory apparatus and method for multiprocessor systems |
US6621827B1 (en) * | 2000-09-06 | 2003-09-16 | Xanboo, Inc. | Adaptive method for polling |
US6640268B1 (en) * | 1998-08-28 | 2003-10-28 | Intel Corporation | Dynamic polling mechanism for wireless devices |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH0798051A (en) * | 1993-04-28 | 1995-04-11 | Tochigi Fuji Ind Co Ltd | Differential device |
-
2003
- 2003-05-19 US US10/440,681 patent/US6931460B2/en not_active Expired - Lifetime
-
2004
- 2004-05-06 TW TW093112793A patent/TWI245993B/en active
- 2004-05-07 WO PCT/US2004/014217 patent/WO2004104730A2/en active Application Filing
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4598363A (en) * | 1983-07-07 | 1986-07-01 | At&T Bell Laboratories | Adaptive delayed polling of sensors |
US5566351A (en) * | 1994-06-20 | 1996-10-15 | International Business Machines Corporation | Adaptive polling system by generating sequence of polling signals whose magnitudes are functionally related to the occurrence of the busy signal |
US6049549A (en) * | 1997-08-14 | 2000-04-11 | University Of Massachusetts | Adaptive media control |
US6449663B1 (en) * | 1998-07-08 | 2002-09-10 | International Business Machines Corporation | Method and apparatus for adjusting an interval of polling a network printer based on changes in working status of the network printer |
US6640268B1 (en) * | 1998-08-28 | 2003-10-28 | Intel Corporation | Dynamic polling mechanism for wireless devices |
US6467011B2 (en) * | 1999-03-19 | 2002-10-15 | Times N Systems, Inc. | Shared memory apparatus and method for multiprocessor systems |
US6621827B1 (en) * | 2000-09-06 | 2003-09-16 | Xanboo, Inc. | Adaptive method for polling |
Cited By (54)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050165983A1 (en) * | 2004-01-26 | 2005-07-28 | Samsung Electronics Co., Ltd. | System and method for processing data in kernel area by a user command |
US20050259748A1 (en) * | 2004-05-21 | 2005-11-24 | Christopher Payson | Buffer for driving display with asynchronous display engine |
US7570270B2 (en) * | 2004-05-21 | 2009-08-04 | Broadcom Corporation | Buffer for driving display with asynchronous display engine |
US20060173971A1 (en) * | 2005-02-01 | 2006-08-03 | Russell Paul F | Adjusting timing between automatic, non-user-initiated pollings of server to download data therefrom |
US7711794B2 (en) * | 2005-02-01 | 2010-05-04 | International Business Machines Corporation | Adjusting timing between automatic, non-user-initiated pollings of server to download data therefrom |
US20060294182A1 (en) * | 2005-06-24 | 2006-12-28 | Brother Kogyo Kabushiki Kaisha | Service providing system, and client, server, and program for the same |
CN100414914C (en) * | 2005-06-24 | 2008-08-27 | 兄弟工业株式会社 | Service providing system and server |
EP1739554A1 (en) * | 2005-06-24 | 2007-01-03 | Brother Kogyo Kabushiki Kaisha | Service providing system, and client, server, and program for the same |
US10015104B2 (en) | 2005-12-28 | 2018-07-03 | Solarflare Communications, Inc. | Processing received data |
US20130117465A1 (en) * | 2005-12-28 | 2013-05-09 | Solarflare Communications, Inc. | Processing received data |
US9319340B2 (en) * | 2005-12-28 | 2016-04-19 | Solarflare Communications, Inc. | Processing received data |
US20070294392A1 (en) * | 2006-06-20 | 2007-12-20 | International Business Machines Corporation | Apparatus, system, and method for intelligent polling support for websphere adapters based on the self-configuration characteristic of an autonomic computing model |
US20080189419A1 (en) * | 2007-02-02 | 2008-08-07 | David Andrew Girle | System and Method to Synchronize OSGi Bundle Inventories Between an OSGi Bundle Server and a Client |
US7721003B2 (en) * | 2007-02-02 | 2010-05-18 | International Business Machines Corporation | System and method to synchronize OSGi bundle inventories between an OSGi bundle server and a client |
US20080253393A1 (en) * | 2007-04-13 | 2008-10-16 | At&T Knowledge Ventures, L.P. | System and method for managing network traffic |
US20110040872A1 (en) * | 2007-04-13 | 2011-02-17 | At&T Intellectual Property I, L.P. | System and method for managing network traffic |
US8774212B2 (en) * | 2007-04-13 | 2014-07-08 | At&T Intellectual Property I, Lp | System and method for managing network traffic |
US7848348B2 (en) * | 2007-04-13 | 2010-12-07 | At&T Intellectual Property I, L.P. | System and method for managing network traffic |
US8572635B2 (en) | 2010-06-23 | 2013-10-29 | International Business Machines Corporation | Converting a message signaled interruption into an I/O adapter event notification |
US8650337B2 (en) | 2010-06-23 | 2014-02-11 | International Business Machines Corporation | Runtime determination of translation formats for adapter functions |
US8478922B2 (en) | 2010-06-23 | 2013-07-02 | International Business Machines Corporation | Controlling a rate at which adapter interruption requests are processed |
US8504754B2 (en) | 2010-06-23 | 2013-08-06 | International Business Machines Corporation | Identification of types of sources of adapter interruptions |
US8505032B2 (en) | 2010-06-23 | 2013-08-06 | International Business Machines Corporation | Operating system notification of actions to be taken responsive to adapter events |
US8510599B2 (en) * | 2010-06-23 | 2013-08-13 | International Business Machines Corporation | Managing processing associated with hardware events |
US8549182B2 (en) | 2010-06-23 | 2013-10-01 | International Business Machines Corporation | Store/store block instructions for communicating with adapters |
US8566480B2 (en) | 2010-06-23 | 2013-10-22 | International Business Machines Corporation | Load instruction for communicating with adapters |
US8458387B2 (en) | 2010-06-23 | 2013-06-04 | International Business Machines Corporation | Converting a message signaled interruption into an I/O adapter event notification to a guest operating system |
US8601497B2 (en) | 2010-06-23 | 2013-12-03 | International Business Machines Corporation | Converting a message signaled interruption into an I/O adapter event notification |
US8615645B2 (en) | 2010-06-23 | 2013-12-24 | International Business Machines Corporation | Controlling the selectively setting of operational parameters for an adapter |
US8621112B2 (en) | 2010-06-23 | 2013-12-31 | International Business Machines Corporation | Discovery by operating system of information relating to adapter functions accessible to the operating system |
US8626970B2 (en) | 2010-06-23 | 2014-01-07 | International Business Machines Corporation | Controlling access by a configuration to an adapter function |
US8631222B2 (en) | 2010-06-23 | 2014-01-14 | International Business Machines Corporation | Translation of input/output addresses to memory addresses |
US8635430B2 (en) | 2010-06-23 | 2014-01-21 | International Business Machines Corporation | Translation of input/output addresses to memory addresses |
US8639858B2 (en) | 2010-06-23 | 2014-01-28 | International Business Machines Corporation | Resizing address spaces concurrent to accessing the address spaces |
US8650335B2 (en) | 2010-06-23 | 2014-02-11 | International Business Machines Corporation | Measurement facility for adapter functions |
US8468284B2 (en) | 2010-06-23 | 2013-06-18 | International Business Machines Corporation | Converting a message signaled interruption into an I/O adapter event notification to a guest operating system |
CN102906707A (en) * | 2010-06-23 | 2013-01-30 | 国际商业机器公司 | Managing processing associated with hardware events |
US9134911B2 (en) | 2010-06-23 | 2015-09-15 | International Business Machines Corporation | Store peripheral component interconnect (PCI) function controls instruction |
US9195623B2 (en) | 2010-06-23 | 2015-11-24 | International Business Machines Corporation | Multiple address spaces per adapter with address translation |
US9213661B2 (en) | 2010-06-23 | 2015-12-15 | International Business Machines Corporation | Enable/disable adapters of a computing environment |
US20110320860A1 (en) * | 2010-06-23 | 2011-12-29 | International Business Machines Corporation | Managing processing associated with hardware events |
US9342352B2 (en) | 2010-06-23 | 2016-05-17 | International Business Machines Corporation | Guest access to address spaces of adapter |
US9383931B2 (en) | 2010-06-23 | 2016-07-05 | International Business Machines Corporation | Controlling the selectively setting of operational parameters for an adapter |
WO2011160712A1 (en) * | 2010-06-23 | 2011-12-29 | International Business Machines Corporation | Managing processing associated with hardware events |
US9626298B2 (en) | 2010-06-23 | 2017-04-18 | International Business Machines Corporation | Translation of input/output addresses to memory addresses |
US9946819B2 (en) * | 2015-01-06 | 2018-04-17 | International Business Machines Corporation | Simulating a large network load |
US20160196365A1 (en) * | 2015-01-06 | 2016-07-07 | International Business Machines Corporation | Simulating a large network load |
US20190080334A1 (en) * | 2017-09-14 | 2019-03-14 | Bank Of America Corporation | Centralized compliance assessment tool |
US10275777B2 (en) * | 2017-09-14 | 2019-04-30 | Bank Of America Corporation | Centralized compliance assessment tool |
US11252070B2 (en) * | 2018-10-09 | 2022-02-15 | Vmware, Inc. | Adaptive polling in software-defined networking (SDN) environments |
US11082354B2 (en) | 2019-06-12 | 2021-08-03 | Vmware, Inc. | Adaptive polling in software-defined networking (SDN) environments |
US11163628B2 (en) * | 2019-12-12 | 2021-11-02 | EMC IP Holding Company LLC | Method, device and computer program product for error management based on a utilization rate of an accelerator device |
US11074202B1 (en) * | 2020-02-26 | 2021-07-27 | Red Hat, Inc. | Efficient management of bus bandwidth for multiple drivers |
US11567884B2 (en) * | 2020-02-26 | 2023-01-31 | Red Hat, Inc. | Efficient management of bus bandwidth for multiple drivers |
Also Published As
Publication number | Publication date |
---|---|
TW200504513A (en) | 2005-02-01 |
WO2004104730A3 (en) | 2005-04-28 |
WO2004104730A2 (en) | 2004-12-02 |
US6931460B2 (en) | 2005-08-16 |
TWI245993B (en) | 2005-12-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6931460B2 (en) | Dynamically self-adjusting polling mechanism | |
US7127568B2 (en) | Throttling in storage systems | |
US6016503A (en) | Methods, systems and computer program products for preemptive avoidance of constraints for shared resources | |
US5768620A (en) | Variable timeout method in a missing-interrupt-handler for I/O requests issued by the same operating system | |
US7363629B2 (en) | Method, system, and program for remote resource management | |
US6341322B1 (en) | Method for interfacing two buses | |
US5819112A (en) | Apparatus for controlling an I/O port by queuing requests and in response to a predefined condition, enabling the I/O port to receive the interrupt requests | |
US7290086B2 (en) | Method, apparatus and program storage device for providing asynchronous status messaging in a data storage system | |
EP2564307B1 (en) | Method for providing asynchronous event notification in systems | |
US8606992B2 (en) | Dynamically switching command types to a mass storage drive | |
US8341314B2 (en) | Managing I/O request in storage system | |
US7676610B2 (en) | Device and method for optimization of target host device process handling according to the status and the priority of the target host device process | |
JP2005092875A (en) | System and method for increasing data throughput by using thread scheduling | |
US9389921B2 (en) | System and method for flexible device driver resource allocation | |
JPH1031631A (en) | Input and output control unit and method for prevention of wrong showing of input and output device operation failure | |
US11005970B2 (en) | Data storage system with processor scheduling using distributed peek-poller threads | |
US5802546A (en) | Status handling for transfer of data blocks between a local side and a host side | |
EP0147574A2 (en) | Resource sharing method between workstations | |
US20030200372A1 (en) | Reducing power consumption of an electronic system having a communication device | |
US6993613B2 (en) | Methods and apparatus for reducing receive interrupts via paced ingress indication | |
US5794069A (en) | Information handling system using default status conditions for transfer of data blocks | |
US7415559B1 (en) | Data processing systems and method for processing work items in such systems | |
US7370081B2 (en) | Method, system, and program for communication of code changes for transmission of operation requests between processors | |
JP2008186211A (en) | Computer system | |
US8006006B2 (en) | System and method for aggregating transmit completion interrupts |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: EMULEX CORPORATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BARRETT, DAVID MICHAEL;REEL/FRAME:014094/0473 Effective date: 20030513 |
|
AS | Assignment |
Owner name: EMULEX DESIGN & MANUFACTURING CORPORATION, CALIFOR Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:EMULEX CORPORATION;REEL/FRAME:014486/0150 Effective date: 20040315 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
FPAY | Fee payment |
Year of fee payment: 8 |
|
AS | Assignment |
Owner name: EMULEX CORPORATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:EMULEX DESIGN AND MANUFACTURING CORPORATION;REEL/FRAME:032087/0842 Effective date: 20131205 |
|
AS | Assignment |
Owner name: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:EMULEX CORPORATION;REEL/FRAME:036942/0213 Effective date: 20150831 |
|
AS | Assignment |
Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH CAROLINA Free format text: PATENT SECURITY AGREEMENT;ASSIGNOR:AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD.;REEL/FRAME:037808/0001 Effective date: 20160201 Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH Free format text: PATENT SECURITY AGREEMENT;ASSIGNOR:AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD.;REEL/FRAME:037808/0001 Effective date: 20160201 |
|
FPAY | Fee payment |
Year of fee payment: 12 |
|
AS | Assignment |
Owner name: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD., SINGAPORE Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS COLLATERAL AGENT;REEL/FRAME:041710/0001 Effective date: 20170119 Owner name: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS COLLATERAL AGENT;REEL/FRAME:041710/0001 Effective date: 20170119 |
|
AS | Assignment |
Owner name: AVAGO TECHNOLOGIES INTERNATIONAL SALES PTE. LIMITE Free format text: MERGER;ASSIGNOR:AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD.;REEL/FRAME:047422/0464 Effective date: 20180509 |
|
AS | Assignment |
Owner name: AVAGO TECHNOLOGIES INTERNATIONAL SALES PTE. LIMITE Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE EXECUTION DATE PREVIOUSLY RECORDED AT REEL: 047422 FRAME: 0464. ASSIGNOR(S) HEREBY CONFIRMS THE MERGER;ASSIGNOR:AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD.;REEL/FRAME:048883/0702 Effective date: 20180905 |