 VOICE Homepage: http://de.os2voice.org |
[Previous Page] [Next Page] [Features] |
|
VOICE Homepage: http://de.os2voice.org |
[Previous Page] [Next Page] [Features] |
|
By Christian
Hennecke © June 2001 |
The last decade's tremendous progress in CPU development brought with it not
only an enormous increases in computing speed but also some problematic side effects,
the most obvious being heat. Starting with small passive coolers we now have arrived
at a point where huge coolers with fans fill up the computer cases. Furthermore,
also hard drives and video cards have their share in turning computers into small
ovens - with top performing models requiring fans of their own. Nowadays it is essential
to have a well-functioning cooling system, if you don't want to see your expensive
hardware turn into smoke. But there is no guarantee that a cooling system is going
to work forever. Another potential problem is the demand for high current of recent
hardware - especially video adapters - leading to instability if it exceeds the
capabilities of the power supply or the motherboard. So what you need is something
that protects your system, monitors the situation, can issue warnings and can take
the appropriate measures in case things get out of hand while the machine is running
unattended. The free StHWMon by Stefan
Milcke is such a monitoring tool and it does the job very well.
StHWMon comes as a WarpIN package. The installation is smooth. If an existing
XWorkplace installation is detected, a plug-in for the XCenter can be installed,
too. More about that later. At the end the user is offered the opportunity to install
national language support for German, English, Italian or Finnish.
There is no general API for getting the measured values from the motherboard,
neither for OS/2 nor other operating systems. Any monitoring software has to access
the chips directly. StHWMon not only supports several of the widely used Winbond
chips, but also the VIA_82C686. To my knowledge there is no other OS/2 tool with
VIA support which is why I started using it originally.
Fig.1: Main display
StHWMon is capable of checking up to three temperature sensors, three fans' rounds
per minute and seven voltages. Figure 1 shows the main display dialog of StHWMon's
GUI. The display is highly configurable. As shown on the left of figure 2, any text
can be entered as a description for each value. A very handy feature, since chip/motherboard
combinations differ in which of the sensors monitors the CPU etc. The code %n inserts
the actual value. Temperatures can also be converted to degrees Fahrenheit. Due
to mass production the chips often don't return the correct value. If you happen
to know the difference between the returned and the real values, you can specify
a separate corrective value for each sensor.
Fig.2: Display setup
So much as for the plain display. To be able to issue warnings or take other
measures, if potentially dangerous values are encountered, the program of course
needs to know what conditions are to be judged as dangerous and which measures ought
to be taken. For this the user can define numerous so-called events that
are all monitored at the same time. The intervals used by StHWMon to query the chip
vary depending on the chip model and the type of sensor and can't be changed by
the user.
Fig.3: Event setup
As shown in figure 3, each event is defined by specifying the condition for one
sensor, e.g. here StHWMon will check if the value of temperature sensor number 2
exceeds 40 degrees Celsius for at least 5 seconds. If this condition should be encountered
the display line of the sensor concerned will always turn to red and the selected
action(s) will be executed. The list of actions contains playing an alarm sound,
which can be either a series of plain beeps or a user-selectable wave file, showing
a dialog box with a warning message like in figure 4, starting a program, or trying
to shutdown the machine via APM. All these actions can be combined at will. I was
unable to test whether the APM shutdown is put on hold until a specified program
has terminated or not.
Fig.4: A sample warning message
In addition to the above GUI there are two alternative ways to use StHWMon, a
daemon and the XCenter plug-in. The daemon can be started from CONFIG.SYS, STARTUP.CMD
or the commandline and remains in the background while using no space on the display.
The XCenter plug-in (see figure 5 for an example) is activated by using the health
monitor widget and its display can be configured similar to the main GUI as
shown in figure 6. If an event's condition is met, the whole widget display turns
red. The widget accepts drag and drop of fonts and colors, by the way. Both the
daemon and the widget start the predefined actions. They offer no possibility to
define events though, but use those defined with the GUI.
Fig.5: XCenter widget display
Fig.6: Default XCenter widget setup
Developers or power users may find interesting that StHWMon comes with interfaces
for C and REXX. There are also some examples on usage.
StHWMon is very reliable. I haven't encountered a single problem with the current
version 0.16 beta build 675. The additional CPU load that it creates by querying
the chip's registers every few seconds is very low - according to XCenter's CPU
load monitor about 1% on an AMD K6-III 450.
There is one caveat: the APM feature ought to be handled with care. Before you
turn it on and leave your machine running with heavy CPU load, be sure to check
if APM power-off works correctly. Unfortunately, this feature doesn't work on many
machines. This is not a bug in StHWMon, but a general design problem with
OS/2 or the motherboard. Mine does a shutdown, but then locks up hard with a TRAP.
This isn't exactly the desired effect and doesn't help at all, in case the CPU fan
should stop turning.
If you know the possible culprit that may cause overheating, e.g. you are running
the SETI@home client in the background or you compile large projects, you can specify
a script in the event definition that invokes a process killer to terminate one
or more processes.
One feature I would like to see added is the possibility to define two conditions
that both must be met to start the actions. While the user can currently define
e.g. a safe voltage range by using two separate events with lower/higher comparisons,
I would like the program to be able to differentiate between less and extremely
dangerous conditions. The compilation of a large project, for instance, could lead
to temperatures that are too high, but as soon as the compiler process is killed
by StHWMon, the CPU fan in combination with OS/2's idle time detection will quickly
bring the temperature down to a healthy level again. When on the other hand the
CPU gets too hot and the CPU fan's rpm value is low or zero, it is definitely high
time for an immediate shutdown.
A small cosmetic glitch in the XCenter widget is that if a value changes in a
way that the number of digits varies, e.g. when changing from 9 to 10 Volts, the
widget adapts its size accordingly. This can be very distracting if it happens frequently.
Earlier versions of the XCenter plug-in that were included in older XWorkplace
releases (pre 0.9.11) are known to have problems on some machines. If you hear a
low beep when the XCenter starts up and the health monitor widget doesn't
show up in XCenter's Add widget menu, it is time to download a later version.
StHWMon can keep your expensive hardware safe - provided it is configured properly
- using actions from warning messages to APM power-off. It offers a very flexible
interface, imposes little load on the processor and is very reliable. The only problem
that prevents APM power-off from working on some machines is caused by a design
flaw of the operating system or the hardware.
StHWMon is an excellent tool that can take at least some of your worries away
so you can remain cool and calm even if your machine doesn't.
Article References:StHWMon 16 beta build 675 |