gkrellm.1

系统任务管理器

some good (or bad) ideas. If you have a recent motherboard, skip the
following.
.PP
Anyway, to do this calibration, take two real CPU temperature readings
corresponding to two sensor reported readings.   To get the real
readings, you can trust that your motherboard manufacturer has done
this calibration and is reporting accurate temperatures in the bios,
or you can put a temperature probe directly on your CPU case (and this
is where things get impractical).
.PP
Here is a hypothetical CPU calibration procedure.  Make sure
.B gkrellm
is configured with default factors of 1.0 and offsets of 0 and is reporting
temperatures in centigrade:
.PP
.IP "1 \(bu"
Power on the machine and read a real temperature T1 from the bios or
a temperature probe.  If reading from the bios, proceed with booting
the OS.  Now record a sensor temperature S1 as reported by
.B gkrellm.
.IP "2 \(bu"
Change the room temperature environment (turn off your AC or change
computer fan exhaust speed).  Now repeat step 1, this time recording
a real temperature T2 and
.B gkrellm
reported sensor temperature S2.
.IP "3 \(bu"
Now you can calculate the correction factor and offset you need
to enter into the Sensor configuration tab:
.PP
.RS
.nf

From:

s - S1     t - T1
------  =  ------
S2 - S1    T2 - T1

         T2 - T1     S2*T1 - S1*T2
t  = s * -------  +  -------------
         S2 - S1         S2 - S1

So:

          T2 - T1                S2*T1 - S1*T2
factor =  -------      offset =  -------------
          S2 - S1                   S2 - S1

.fi
.RE

.SS "Voltage Sensor Corrections"
.PP
You need to read this section only if you think the default voltage correction
factors and offsets are incorrect.  For Linux and lm_sensors and sysfs sensors
 this would be if
.B gkrellm
does not know about your particular sensor chip.
For MBM with Windows, the default values should be correct.
.PP
Motherboard voltage measurements are made by a variety of sensor
chips which are capable of measuring a small positive voltage.
GKrellM can display these voltage values and can apply a correction
factor, offset, and for the negative voltages of some chips (lm80),
a level shifting reference voltage to the displayed voltage.
There are four cases to consider:
.PP
.IP "1 \(bu"
Low valued positive voltages may be directly connected to the input
pins of the sensor chip and therefore need no correction.  For these,
the correction factor should be 1.0 and the offset should be 0.
.IP "2 \(bu"
Higher valued positive voltages will be connected to the input pins
of the sensor chip through a 2 resistor attenuation circuit.  For these,
the correction factor will be a ratio of the resistor values and the
offset will be 0.
.IP "3 \(bu"
Negative voltages will be connected to the input pins of the sensor
through a 2 resistor attenuation circuit with one of the resistors
connected to a positive voltage to effect a voltage level shift.
For these (lm80), the correction factor and offset will be ratios of the
resistor values, and a reference voltage must be used.
.IP "4 \(bu"
Some sensor chips (w83782, lm78) are designed to handle negative inputs
without requiring an input resistor connected to a voltage reference.
For these, there will be a correction factor and a possible offset.
.PP
.RS
.nf

For cases 2 and 3, the sensor chip input network looks like:

    Vs o----/\\/\\/---o-------------o Vin
             R1     |
                    o--/\\/\\/--o Vref
                        R2
.fi
.RE
.PP
.IP "where,"
.RS
.TP
.I "Vs"
is the motherboard voltage under measurement
.TP
.I "Vin"
is the voltage at the input pin of the sensor chip and therefore is
the voltage reading that will need correction.
.TP
.I "Vref"
is a level shifting voltage reference.  For case 2, Vref is ground
or zero.  For case 3, Vref will be one of the positive motherboard
voltages.
.RE
.PP

The problem then is to compute correction factors and offsets as a function
of R1 and R2 so that GKrellM can display a computed motherboard voltage Vs
as a function of a measured voltage Vin.
.PP
Since sensor chip input pins are high impedance, current into the pins may
be assumed to be zero.  In that case, the current through R1 equals current
through R2, and we have:
.PP
.RS
.nf
    (Vs - Vin)/R1 = (Vin - Vref)/R2

Solving for Vs as a function of Vin:

    Vs = Vin * (1 + R1/R2)  -  (R1/R2) * Vref

So, the correction factor is:  1 + R1/R2
    the correction offset is:  - (R1/R2)
    Vref is specified in the config separately from
    the offset (for chips that need it).

.fi
.RE
.PP
Fortunately there seems to be a standard set of resistor values used
for the various sensor chips which are documented in the lm_sensor
documentation.  The GKrellM sensor corrections are similar to the compute
lines you find with lm_sensors, with the difference that lm_sensors has an
expression evaluator which does not require that compute lines be simplified
to the single factor and offset required by GKrellM.  But you can easily
calculate the factor and offset.  For example, this lm_sensor compute line
for a case 2 voltage:
.PP
.RS
.nf
    compute in3 ((6.8/10)+1)*@ ,  @/((6.8/10)+1)

.fi
.RE
.PP
yields a correction factor of ((6.8/10)+1) = 1.68
and an offset of zero.
.PP
Note that the second compute line expression is not relevant in GKrellM
because there is never any need to invert the voltage reading calculation.
Also, the compute line '@' symbol represents the Vin voltage.
.PP
A more complicated compute line for a case 3 voltage:
.PP
.RS
.nf

    compute in5 (160/35.7)*(@ - in0) + @, ...

can be rewritten:

    compute in5 (1 + 160/35.7)*@ - (160/35.7)*in0, ...

so the correction factor is  (1 + 160/35.7) = 5.48
and the correction offset is -(160/35.7) = -4.48
and the voltage reference Vref is in0
.fi
.RE
.PP
Here is a table of correction factors and offsets based on some typical
compute line entries from /etc/sensors.conf:
.PP
.RS
.nf

       Compute line                 Factor  Offset  Vref
       -------------------------------------------------
lm80   in0 (24/14.7 + 1) * @        2.633     0       -
       in2 (22.1/30 + 1) * @        1.737     0       -
       in3 (2.8/1.9) * @            1.474     0       -
       in4 (160/30.1 + 1) * @       6.316     0       -
       in5 (160/35.7)*(@-in0) + @   5.482    -4.482  in0
       in6 (36/16.2)*(@-in0) + @    3.222    -2.222  in0

LM78   in3 ((6.8/10)+1)*@           1.68      0       -
       in4 ((28/10)+1)*@            3.8       0       -
       in5 -(210/60.4)*@           -3.477     0       -
       in6 -(90.9/60.4)*@          -1.505     0       -

w83782 in5 (5.14 * @) - 14.91       5.14    -14.91    -
       in6 (3.14 * @) -  7.71       3.14     -7.71    -

.fi
.RE

.SS "Command launching"
.PP
Many monitors can be set up to launch a command when you click on
the monitor label.  When a command is configured for a monitor, its
label is converted into a button which becomes visible when the mouse
enters the panel or meter area of the label.  If the command is a
console command (doesn't have a graphical user interface), then
the command must be run in a terminal window such as xterm, eterm,
or Gnome terminal.  For example running the "top" command would take:
.TP
xterm -e top
.PP
You can use the command launching feature to run commands related to
monitoring functions, or you may use it to have a convenient launch
for any command.  Since
.B gkrellm
is usually made sticky, you can have
easy access to several frequently used commands from any desktop.
This is intended to be a convenience and a way to maximize utilization
of screen real estate and not a replacement for more full featured
command launching from desktops such as Gnome or KDE or others.
Some launch ideas for some monitors could be:
.TP
.I calendar:
gnomecal, evolution, or ical
.TP
.I CPU:
xterm -e top or gps or gtop
.TP
.I inet:
gftp or xterm -e ftpwho
.TP
.I net:
mozilla, galeon, skipstone, or xterm -e slrn -C-
.PP
And so on... Tooltips can be set up for these commands.

.SS "Alerts"
.PP
Most monitors can have alerts configured to give warnings and alarms
for data readings which range outside of configurable limits.  Where
useful, a delay of the alert trigger can be configured.  A warning or
alarm consists of an attention grabbing decal appearing and an optional
command being executed.
For most monitors the command may contain the
same substitution variables which are available for display in the
chart or panel label format strings and are documented on configuration
Info pages.  Additionally, the hostname may be embedded in the command
with the $H substitution variable.
.PP
If you have festival installed, either a warn or alarm command
could be configured to speak something.  For example a CPU temperature
alert warn command could just speak the current temperature with:
.nf

    sh -c "echo warning C P U is at $s degrees | esddsp festival --tts"

.fi
Assuming you have esd running.

.SH "THEMES"
.PP
A theme is a directory containing image files and a
.IR gkrellmrc
configuration file.  The theme directory may be installed in
several locations:
.PP
.RS
.nf
~/.gkrellm2/themes
/usr/local/share/gkrellm2/themes
/usr/share/gkrellm2/themes
.fi
.RE
.PP
For compatibility with Gtk themes, a
.B gkrellm
theme may also be installed as:
.PP
.RS
.nf
~/.themes/THEME_NAME/gkrellm2
/usr/share/themes/THEME_NAME/gkrellm2
.fi
.RE
.PP
Finally, a theme you simply want to check out can be untarred anywhere and
used by running:
.PP
.RS
.nf
gkrellm -t path_to_theme
.fi
.RE
.PP
If you are interested in writing a theme, go to the Themes page
at
.IR http://www.gkrellm.net
and there you will find a Theme making reference.


.SH "PLUGINS"
.PP
.B gkrellm
tries to load all plugins (shared object files ending in .so)
it finds in your plugin directory
.IR ~/.gkrellm2/plugins.
The directories
.IR /usr/local/lib/gkrellm2/plugins
and
.IR /usr/lib/gkrellm2/plugins
are also searched for plugins to install.
.PP
Some plugins may be available only as source files and they will
have to be compiled before installation.  There should be instructions
for doing this with each plugin that comes in source form.
.PP
If you are interested in writing a plugin, go to the Plugins page
at
.IR http://www.gkrellm.net
and there you will find a Plugin programmers reference.


.SH "CLIENT/SERVER"
When a local
.B gkrellm
runs in client mode and connects to a remote
.B gkrellmd
server all builtin monitors collect
their data from the server.  However, the client
.B gkrellm
process is running
on the local machine, so any enabled plugins will run in the local
context (Flynn is an exception to this since it derives its data from
the builtin CPU monitor).  Also, any command launching will run commands
on the local machine.

.SH "FILES"
.TP
.I ~/.gkrellm2
User gkrellm directory where are located configuration files, user's plugins
and user's themes.
.TP
.I ~/.gkrellm2/plugins
User plugin directory.
.TP
.I /usr/lib/gkrellm2/plugins
System wide plugin directory.
.TP
.I /usr/local/lib/gkrellm2/plugins
Local plugin directory.
.TP
.I ~/.gkrellm2/themes
User theme directory.
.TP
.I ~/.themes/THEME_NAME/gkrellm2
User theme packaged as part of a user Gtk theme.
.TP
.I /usr/share/gkrellm2/themes
System wide theme directory.
.TP
.I /usr/local/share/gkrellm2/themes
Local theme directory.
.TP
.I /usr/share/themes/THEME_NAME/gkrellm2
System wide theme packaged as part of a system wide Gtk theme.

.SH "AUTHORS"

Bill Wilson <[e-mail]>.
http://www.gkrellm.net/

.SH "SEE ALSO"
.BR fstab (5),
.BR sudo (1),
.BR mount (8),
.BR pppd (8),
.BR umount (8)