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.