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. If you are running a multi-processor system, you will get one "user" graph for each CPU. However, even then you will only have one "IRQ" graph because per definition, &os2; processes all interrupts on the first CPU in the system. See the remarks below for details about this.

Note that you can drag and drop fonts and colors onto the pulse widget. Besides, it is sizeable.

Implementation Details

Internally, the pulse widget uses the DosPerfSysCall API (see the documentation for DosPerfSysCall in the Toolkit documentation*). This API has the advantage that in order to measure CPU activity, one can directly access the performance counters in the &os2; 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 &os2; 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).

The IBM documentation for DosPerfSysCall 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 &os2; 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 &os2; kernel or a device driver in the regular execution flow of processes and threads, as controlled by the scheduler in the &os2; 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, network adapters, and serial and printer communications. These devices cannot afford to wait until the &os2; scheduler has finished a process timeslice and is ready to switch to another task. Instead, when an IRQ comes in, the &os2; 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 &os2; 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 normal. 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.