readme

系统任务管理器

physically possible because it requires that somehow you can get a real
CPU temperature reading.  So, the calibration discussion which follows
should probably be considered an academic exercise that might give you
some good (or bad) ideas.  If you have a recent motherboard, skip the
following.

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).

Here is a hypothetical CPU calibration procedure.  Make sure GKrellM is
configured with default factors of 1.0 and offsets of 0 and is reporting
temperatures in centigrade:

    1) 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 GKrellM.
    2) 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 GKrellM reported sensor temperature S2.
    3) Now you can calculate the correction factor and offset you need
       to enter into the Sensor configuration tab:
           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


Voltage Sensor Corrections
--------------------------
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 GKrellM does not know about your particular sensor chip.
For MBM with Windows, the default values should be correct.

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:

  1) 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.

  2) 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.

  3) 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.

  4) 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.

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

    Vs o----/\/\/---o-------------o Vin
             R1     |
                    o--/\/\--o Vref
                        R2
where,
    Vs   is the motherboard voltage under measurment
    Vin  is the voltage at the input pin of the sensor chip and therefore is
         the voltage reading that will need correction.
    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.

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.

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:

    (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).

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:

    compute in3 ((6.8/10)+1)*@ ,  @/((6.8/10)+1)

yields a correction factor of ((6.8/10)+1) = 1.68
and an offset of zero.

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.

A more complicated compute line for a case 3 voltage:

    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

Here is a table of correction factors and offsets based on some typical
compute line entries from /etc/sensors.conf:

       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    -



Command launching
=================
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:

    xterm -e top

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 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:

   calendar: gnomecal, evolution, or ical
        CPU: xterm -e top  or  gps  or  gtop
       inet: gftp  or  xterm -e ftpwho
        net: mozilla, galeon, skipstone,  or  xterm -e slrn -C-
and so on...

Tooltips can be set up for these commands.


Alerts
======
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.

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:

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

Assuming you have esd running.


Installing a Theme for GKrellM
==============================

A theme is a directory containing image files and a gkrellmrc
configuration file.  The theme directory may be installed in
several locations:

	~/.gkrellm2/themes
	/usr/local/share/gkrellm2/themes
	/usr/share/gkrellm2/themes

For compatibility with Gtk themes, a GKrellM theme may also be installed
as:
	~/.themes/THEME_NAME/gkrellm2
	/usr/share/themes/THEME_NAME/gkrellm2

Finally, a theme you simply want to check out can be untarred anywhere
and used by running:

	gkrellm -t path_to_theme

Read the Themes file if you want more information or are interested in
making a new theme for GKrellM.


Plugins
=======

GKrellM tries to load all plugins (shared object files ending in .so)
it finds in your plugin directory ~/.gkrellm2/plugins.  The directories
/usr/local/lib/gkrellm2/plugins and /usr/lib/gkrellm2/plugins are
also searched for plugins to install.

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.

If you are interested in writing a plugin, go to the Plugins page
at http://gkrellm.net and there you will find a Plugin programmers
reference and Plugins-changelog.


Client/Server
=============
When gkrellm connects to a gkrellmd server all builtin monitors collect
their data from the server.  However, the gkrellm process is running
on the local machine, so any enabled plugins will run in the local
context (Flynn is an example exception to this since it derives its data
from the builtin CPU monitor).  Also, any command launching will run
commands on the local machine.