The XCenter "Pulse" widget displays the current CPU load together with a graph of past CPU activity. This is updated once a second and quite similar to the respective monitor in the WarpCenter.

The display will roughly look like the following:

The cyan part of the graph represents the "user" load of the system, while the blue part represents the "IRQ" load. The percentage that is printed in the center always represents the current combined "user" and "IRQ" loads. See the remarks below for details about this.

The pulse widget accepts colors and fonts that are dropped on it. Besides, it is sizeable.

Presently, the pulse widget can only display the load of the first CPU, in case you are running OS/2 on a multi-processor system.

Implementation Details

Internally, the pulse widget uses the DosPerfSysCall API. This API has the advantage that in order to measure CPU activity, one can directly access the performance counters in the OS/2 kernel instead of having to run a second idle-time thread which consumes all remaining CPU time itself (and therefore additional battery power on laptops).

As a result, running the pulse widget does not consume additional CPU time except for the time needed to paint the widget itself. In other words, the pulse widget does not compute CPU load itself, it only queries the OS/2 kernel for the current load and displays this in a graph.

The widget's own overhead for painting is also the reason why you will probably never see a CPU load of zero, even if you are not currently doing anything with your system. On the author's system (a Pentium II-400), the CPU load never goes below 0.7% with the standard widget size.

Requirements

The DosPerfSysCall API has only been introduced fairly recently and may not work on your system. It should work with Warp 4 and above (or Warp 3 with an equivalent fixpak level; should be fixpak 26).

In addition, the IBM documentation for this API states that a Pentium processor is required for the kernel performance counters to work.

If the widget does not display a graph but "E xxx" only (with xxx being a standard OS/2 error code), an error occured. Most probably, you will get "E 182", which means that the DosPerfSysCall API wasn't found on your system. For other error codes, you can try typing HELP SYSxxx on a command line.

"User" and "IRQ" load

For each performance snapshot, DosPerfSysCall returns values for "user" and "IRQ" loads, respectively.

The "user" load is the time that was spent in "task time" code. Essentially, this means that the CPU was busy executing code in either an application or the OS/2 kernel or a device driver in the regular execution flow of processes and threads, as controlled by the scheduler in the OS/2 kernel. (See "Processes and threads" for details.)

By contrast, the "IRQ" load represents the time that was needed to process interrupts. As you might know, interrupts are a way for hardware components to signal to the CPU that some important event occured which needs to be serviced immediately. Most commonly, interrupts are raised by hard disks, sound cards, and network adapters. These devices cannot afford to wait until the OS/2 scheduler has finished a process timeslice and is ready to switch to another task. Instead, when an IRQ comes in, the OS/2 kernel interrupts the regular scheduling sequence and calls an interrupt handler instead, which, in most cases, will be code in some device driver. (In general, only OS/2 device drivers can install interrupt handlers.) For example, if an interrupt from the hard disk comes in, code in IBM1S506.ADD will be called immediately to service the interrupt.

If you never see any IRQ load on your system, this is not a problem. This is probably the case if you do not have any network adapters installed and you have busmastering enabled for your hard disks. However, if you have a high IRQ load, you might consider taking measurements to reduce it -- enable busmastering for your hard disks and/or get a network adapter which is capable of busmastering.