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.