fancontrol

title: fancontrol(8)

text:
# fancontrol(8)

## NAME
fancontrol - automated software based fan speed regulation

## SYNOPSIS
fancontrol [configfile]

## DESCRIPTION
fancontrol is a shell script for use with lm_sensors. It reads its configuration from a file, then calculates fan speeds from temperatures and sets the corresponding PWM outputs to the computed values.

## WARNING
Please be careful when using the fan control features of your mainboard, in addition to the risk of burning your CPU, at higher temperatures there will be a higher wearout of your other hardware components, too. So if you plan to use these components in 50 years, maybe you shouldn't use fancontrol at all. Also please keep in mind most fans aren't designed to be powered by a PWMed voltage.

In practice it doesn't seem to be a major issue, the fans will get slightly warmer, just be sure to have a temperature alarm and/or shutdown call, in case some fan fails, because you probably won't hear it anymore ;)

## CONFIGURATION
For easy configuration, there's a script named pwmconfig(8) which lets you interactively write your configuration file for fancontrol. Alternatively you can write this file yourself using the information from this manpage.

Since most of you are going to use pwmconfig(8) script, the config file syntax will be discussed last. First I'm going to describe the various variables available for changing fancontrol's behaviour:

INTERVAL

This variable defines at which interval in seconds the main loop of fancontrol will be executed

DEVPATH

Maps hwmon class devices to physical devices. This lets fancontrol check that the configuration file is still up-to-date.

DEVNAME

Records hwmon class device names. This lets fancontrol check that the configuration file is still up-to-date.

FCTEMPS

Maps PWM outputs to temperature sensors so fancontrol knows which temperature sensors should be used for calculation of new values for the corresponding PWM outputs.

FCFANS

Records the association between a PWM output and a fan input. Then fancontrol can check the fan speed and restart it if it stops unexpectedly.

MINTEMP

The temperature below which the fan gets switched to minimum speed.

MAXTEMP

The temperature over which the fan gets switched to maximum speed.

MINSTART

Sets the minimum speed at which the fan begins spinning. You should use a safe value to be sure it works, even when the fan gets old.

MINSTOP

The minimum speed at which the fan still spins. Use a safe value here, too.

MINPWM

The PWM value to use when the temperature is below MINTEMP. Typically, this will be either 0 if it is OK for the fan to plain stop, or the same value as MINSTOP if you don't want the fan to ever stop. If this value isn't defined, it defaults to 0 (stopped fan).

MAXPWM

The PWM value to use when the temperature is over MAXTEMP. If this value isn't defined, it defaults to 255 (full speed).

AVERAGE

How many last temperature readings are used to average the temperature. It can be used to smoothen short temperature peaks. If this value isn't defined, it defaults to 1 (no averaging).

The configuration file format is a bit strange:

```
VARIABLE=chip/pwmdev=value chip/pwmdev2=value2
VARIABLE2=...
```

Each variable has its own line. The variable name is followed by an equal sign and the device=value pairs. These consist of the path to the pwm output for which the value is valid, equal sign followed by the value and are separated by a blank. Path can be absolute or relative (from /sys/bus/i2c/devices or /sys/class/hwmon depending on the kernel version). Example:

MINTEMP=hwmon0/device/pwm1=40 hwmon0/device/pwm2=54

You have to play with the temperature values a bit to get happy. For initial setup I recommend using the pwmconfig script. Small changes can be made by editing the config file directly following the rules above.

Upon starting, fancontrol will make sure that all referenced devices do exist and match what they were at configuration time, and that all referenced sysfs files do exist. If not, it will quit immediately, upon the assumption that the configuration file may be out-of-sync with the loaded kernel drivers.

## THE ALGORITHM
fancontrol first reads its configuration, writes it to arrays and loops its main function. This function gets the temperatures and fanspeeds from kernel driver files and calculates new speeds depending on temperature changes, but only if the temp is between MINTEMP and MAXTEMP. After that, the new values are written to the PWM outputs. Currently the speed increases linearly with rising temperature. This way you won't hear your fans most of the time at best.

## SEE ALSO
pwmconfig(8), sensors(1).

## AUTHOR
Marius Reiner <marius.reiner@hdev.de>


isadump

title: isadump(8)

summary: examine ISA registers

text:
# isadump(8)

## NAME
isadump - examine ISA registers

## SYNOPSIS
isadump [-y] [-W|-L] [-k V1,V2...] addrreg datareg [bank [bankreg]] #for I2C-like access

isadump -f [-y] [-W|-L] address [range [bank [bankreg]]] #for flat address space

## DESCRIPTION
isadump is a small helper program to examine registers visible through the ISA bus. It is intended to probe any chip that lives on the ISA bus working with an address register and a data register (I2C-like access) or a flat range (of up to 256 bytes).

## OPTIONS
-f

Enable flat address space mode.

-y

Disable interactive mode. By default, isadump will wait for a confirmation from the user before messing with the ISA bus. When this flag is used, it will perform the operation directly. This is mainly meant to be used in scripts.

-k V1,V2...

Specify a comma-separated list of bytes to send as the key sequence to enter the chip configuration mode. Most Super-I/O chips need this. Known key sequences are: 0x87,0x01,0x55,0x55 for ITE, 0x55 for SMSC, 0x87,0x87 for Winbond and VIA, none needed for National Semiconductor.

-W

Perform 16-bit reads.

-L

Perform 32-bit reads.

## OPTIONS (I2C-like access mode)
At least two options must be provided to isadump. addrreg contains the ISA address of the address register for the chip to probe; datareg contains the address of the data register. Both addresses are integers between 0x0000 and 0x3FFF. Usually, if the chip's base address is 0x0nn0, the address register is at 0x0nn5 and the data register is at 0x0nn6. The most common base address for hardware monitoring chips is 0x0290.

For Super-I/O chips, address register is typically at 0x2E with data register at 0x2F.

The bank and bankreg parameters are useful on the Winbond chips as well as on Super-I/O chips. bank is an integer between 0 and 31, and bankreg is an integer between 0x00 and 0xFF (default value: 0x4E for Winbond chips, 0x07 for Super-I/O chips). The W83781D datasheet has more information on bank selection.

## OPTIONS (flat address space mode)
In flat mode, only one parameter is mandatory. address contains the ISA address of the chip to probe; it is an integer between 0x0000 and 0xFFFF. If provided, range is how many bytes should be read (must be a multiple of 16). If the range isn't provided, it defaults to 256 bytes and the address is forcibly aligned on a 256-byte boundary.

The bank and bankreg parameters are useful on the National Semiconductor PC87365 and PC87366 Super-I/O chips. bank is an integer between 0 and 31, and bankreg is an integer between 0x00 and 0xFF (default value: 0x09; must fit in the specified range). See the PC87365 datasheet for more information on bank selection.

## NOTES
If no bank is specified, no bank change operation is performed.

If a bank is specified, the original value is restored before isadump exits.

Dumping Super-I/O chips is typically a two-step process. First, you will have to access the main Super-I/O address using a command like: isadump 0x2e 0x2f 0x09. This will select logical device 9 (correct value depend on the chip). At 0x60 you will find the logical device address word, for example "ec c0". Then you can use a command like: isadump -f 0xecc0 16. This will dump the logical device registers. The correct range depends on the chip.

## WARNING
Poking around in ISA data space is extremely dangerous. Running isadump with random parameters can cause system crashes, data loss, and worse! Be extremely careful when using this program.

## SEE ALSO
i2cdump(8), isaset(8)

## AUTHOR
Frodo Looijaard, Mark D. Studebaker, and the lm_sensors group (https://hwmon.wiki.kernel.org/lm_sensors)

This manual page was originally written by David Z Maze <dmaze@debian.org> for the Debian GNU/Linux system. It was then reviewed and augmented by the lm_sensors team and is now part of the lm_sensors source distribution.


isaset

title: isaset(8)

summary: set ISA registers

text:
# isaset(8)

## NAME
isaset - set ISA registers

## SYNOPSIS
isaset [-y] [-W|-L] addrreg datareg address value [mask] #for I2C-like access

isaset -f [-y] [-W|-L] address value [mask] #for flat address space

## DESCRIPTION
isaset is a small helper program to set registers visible through the ISA bus.

## OPTIONS
-f

Enable flat address space mode.

-y

Disable interactive mode. By default, isaset will wait for a confirmation from the user before messing with the ISA bus. When this flag is used, it will perform the operation directly. This is mainly meant to be used in scripts.

-W

Perform a 16-bit write.

-L

Perform a 32-bit write.

## OPTIONS (I2C-like access mode)
Four options must be provided to isaset. addrreg contains the ISA address of the address register for the chip to probe; datareg contains the address of the data register. Both addresses are integers between 0x0000 and 0x3FFF. Usually, if the chip's base address is 0x0nn0, the address register is at 0x0nn5 and the data register is at 0x0nn6. The most common base address for hardware monitoring chips is 0x0290. For Super-I/O chips, address register is typically at 0x2E with data register at 0x2F. The address and value parameters are two integers between 0x00 and 0xFF. isaset will write value value to address address. An optional mask can be provided as a fifth parameter, preserving unmasked bits at the written location.

## OPTIONS (flat address space mode)
In flat mode, two parameters must be provided. address contains the ISA address of the register to write to; it is an integer between 0x0000 and 0xFFFF. Basically, it is the sum of the chip's base address and the chip register's address. isaset will write value value at this address. An optional mask can be provided as a third parameter, preserving unmasked bits at the written location.

## WARNING
Poking around in ISA data space is extremely dangerous. Running isaset with random parameters can cause system crashes, data loss, and worse! Be extremely careful when using this program.

## SEE ALSO
i2cset(8), isadump(8)

## AUTHOR
Mark D. Studebaker, and the lm_sensors group (https://hwmon.wiki.kernel.org/lm_sensors)

This manual page was shamelessly ripped from the i2cset and isadump manual pages by Jean Delvare.


pwmconfig

title: pwmconfig(8)

text:
# pwmconfig(8)

## NAME
pwmconfig - tests the PWM outputs of sensors and configures fancontrol

## SYNOPSIS
pwmconfig

## WARNING
pwmconfig will attempt to stop your fans, one at a time, for approximately 5 seconds each. This may cause your processor temperature to rise. Verify that all fans are running at normal speed after this program has exited. pwmconfig does its best to check that the fans are spinning when they are supposed to, but due to the diversity of available motherboards and fans, it shouldn't be blindly trusted. Always verify by yourself.

It is strongly recommended to run pwmconfig at a time when there is no significant system load, to minimize the risk of overheating.

## DESCRIPTION
pwmconfig searches your sensors for pulse width modulation (PWM) controls, and tests each one to see if it controls a fan on your motherboard. Note that many motherboards do not have PWM circuitry installed, even if your sensor chip supports PWM.

When a connection is established between a PWM control and a fan, pwmconfig can generate a detailed correlation, to show how a given fan is responding to various PWM duty cycles.

Lastly, pwmconfig will enter in fancontrol configuration mode (unless you decide to skip that part.) In this mode, you are invited to enter several parameters which will determine how the fancontrol daemon regulates the speed of one or more fans in your system based on temperature measurements. In particular, you will have the opportunity to establish mappings between fans and temperature inputs, define the temperature range over which the speed of the fan should be adjusted dynamically, the minimum speed at which the fan should spin, etc. See fancontrol(8) for additional information.

## BUGS
The term "PWM" is used because most fan control systems in computers are based on pulse width modulation. Some motherboards however use DC variation instead. So, the term "PWM" should be seen as a generic term for "fan speed control", regardless of the actual method used.

## SEE ALSO
fancontrol(8), sensors(1).

## AUTHORS
Marius Reiner <marius.reiner@hdev.de>, Jean Delvare <jdelvare@suse.de>


sensord

title: sensord(8)

summary: Sensor information logging daemon.

text:
# sensord(8)

## NAME
sensord - Sensor information logging daemon.

## SYNOPSIS
sensord [ options ] [ chips ]

## DESCRIPTION
Sensord is a daemon that can be used to periodically log sensor readings from hardware health-monitoring chips to syslog(3) or a round-robin database (RRD) and to alert when a sensor alarm is signalled; for example, if a fan fails, a temperature limit is exceeded, etc.

## OPTIONS
-i, --interval time

Specify the interval between scanning for sensor alarms; the default is to scan every minute. The time should be specified as a raw integer (seconds) or with a suffix `s' for seconds, `m' for minutes or `h' for hours; for example, the default interval is `60' or `1m'.

Specify an interval of zero to suppress scanning explicitly for alarms.

-l, --log-interval time

Specify the interval between logging all sensor readings; the default is to log all readings every half hour. The time is specified as before; e.g., `30m'.

Specify an interval of zero to suppress logging of regular sensor readings.

-1, --oneline

Log sensor value, chip, and adapter on one line for easier parsing.

-t, --rrd-interval time

Specify the interval between logging all sensor readings to a round-robin database; the default is to log all readings every five minutes if a round-robin database is configured. The time is specified as before; e.g., `5m'.

-T, --rrd-no-average

Specify that the round-robin database should not be averaged.

-r, --rrd-file file

Specify a round-robin database into which to log all sensor readings; e.g., `/var/log/sensord.rrd'. This database will be created if it does not exist. By default, no round-robin database is used. See the section ROUND ROBIN DATABASES below for more details.

-c, --config-file file

Specify a libsensors(3) configuration file. If no file is specified, the libsensors default configuration file is used.

-p, --pid-file file

Specify what PID file to write; the default is to write the file `/var/run/sensord.pid'. You should always specify an absolute path here. The file is removed when the daemon exits.

-f, --syslog-facility facility

Specify the syslog(3) facility to use when logging sensor readings and alarms; the default is to use daemon. Other possible facilities include local0 through local7, and user.

-g, --rrd-cgi directory

Prints out a sample rrdcgi(1) CGI script that can be used to display graphs of recent sensor information in a Web page, and exits. You must specify the world-writable, Web-accessible directory where the graphs should be stored; the CGI script assumes that this will be accessed under the `/sensord/' directory on the Webserver. See the section ROUND ROBIN DATABASES below for more details.

-a, --load-average

Include the load average in the RRD database. You should also specify this flag when you create the CGI script.

-d, --debug

Prints a small amount of additional debugging information.

-h, --help

Prints a help message and exits.

-v, --version

Displays the program version and exits.

## CHIPS
To restrict the devices that are scanned by this daemon, you may optionally specify a list of chip names. By default, all available chips are scanned.

A typical chip name would be `w83782d-*' (you may want to escape the `*' for your shell) which would scan any W83782D chips on any bus. See sensors.conf(5) for more details. Another option is to simply not load the sensor modules for chips in which you have no interest.

## SIGNALS
Upon receipt of a SIGTERM (see signal(7) for details) this daemon should gracefully shut down.

Upon receipt of a SIGHUP, this daemon will rescan the kernel interface for chips and features, and reload the libsensors configuration file.

## LOGGING
All messages from this daemon are logged to syslog(3) under the program name `sensord' and facility daemon, or whatever is specified on the command line.

Regular sensor readings are logged at the level info. Alarms are logged at the level alert. Inconsequential status messages are logged at the minimum level, debug, when debugging is enabled.

You can use an appropriate `/etc/syslog.conf' file to direct these messages in a useful manner. See syslog.conf(5) for full details. Assuming you set the logging facility to local4, the following is a sample configuration:

```
# Sample syslog.conf entries
*.info;...;local4.none;local4.warn  /var/log/messages
local4.info                        -/var/log/sensors
local4.alert                        /dev/console
local4.alert                        *
```

The first line ensures that regular sensor readings do not clutter `/var/log/messages'; we first say `local4.none' to eliminate informational messages; then `local4.warn' to enable warnings and above. The second line says to log all regular sensor readings to `/var/log/sensors'; the leading hyphen `-' means that this file is not flushed after every message. The final two lines ensure that alarms are printed to the system console as well as to all connected users (in addition to `/var/log/messages' and `/var/log/sensors').

## LOG ROTATION
On a typical system with a good sensor chip, expect about 2KB per sensor reading in the log file. This works out at about 3MB per month. You should be rotating your syslog files anyway, but just to be sure you'll want to use something like logrotate(8) or equivalent. You might, for example, want an entry in `/etc/logrotate.d/syslog' containing:

```
# Sample logrotate.d entry
/var/log/sensors {

    postrotate

        /usr/sbin/killall -HUP syslogd

    endscript
}
```

Note, of course, that you want to restart syslogd(8) and not sensord(8)

## ALARMS
Alarms generally indicate a critical condition; for example, a fan failure or an unacceptable temperature or voltage. However, some sensor chips do not support alarms, while others are incorrectly configured and may signal alarms incorrectly.

Note that some drivers may lack support for alarm reporting even though the chips they support do have alarms. As of Linux 2.6.23, many drivers still don't report alarms in a format suitable for libsensors 3.

## BEEPS
If you see `(beep)' beside any sensor reading, that just means that your system is configured to issue an audio warning from the motherboard if an alarm is signalled on that sensor.

## ROUND ROBIN DATABASES
Sensord(8) provides support for storing sensor readings in a round-robin database. This may be a useful alternative to the use of syslog(3).

Round-robin databases are constant-size databases that can be used to store, for example, a week's worth of sensor readings. Subsequent readings stored in the database will overwrite readings that are over a week old. This capability is extremely useful because it allows useful information to be stored in an easily-accessible manner for a useful length of time, without the burden of ever-growing log files.

The rrdtool(1) utility and its associated library provide the basic framework for the round-robin database beneath sensord(8). In addition, the rrdcgi(1) and rrdgraph(1) utilities provide support for generating graphs of these data for display in a Web page.

If you wish to use the default configuration of round-robin database, which holds one week of sensor readings at five-minute intervals, then simply start sensord(8) and specify where you want the database stored. It will automatically be created and configured using these default parameters.

If you wish readings to be stored for a longer period, or want multiple readings to be averaged into each database entry, then you must manually create and configure the database before starting sensord(8). Consult the rrdcreate(1) manual for details. Note that the database must match exactly the names and order of sensors read by sensord(8). It is recommended that you create the default database and then use rrdinfo(1) to obtain this information, and/or rrdtune(1) to change it.

After creating the round-robin database, you must then configure your Web server to display the sensor information. This assumes that you have a Web server preconfigured and functioning on your machine. Sensord(8) provides a command-line option --rrd-cgi to generate a basic CGI script to display these graphs; you can then customize this script as desired. Consult the rrdcgi(1) manual for details. This CGI script requires a world-writable, Web-accessible directory into which to write the graphs that it generates.

An example of how to set up Web-accessible graphs of recent sensor readings follows:

```
sensord --log-interval 0 \

  --load-average \

  --rrd-file /var/log/sensord.rrd
```

Here, we start sensord(8) and configure it to store readings in a round-robin database; note that we disable logging of sensor readings to syslog(3), and enable logging of the load average.

```
mkdir /var/www/sensord
chown www-data:staff /var/www/sensord
chmod a=rwxs /var/www/sensord
```

Here, we create a world-writable, Web-accessible directory in which graphs will be stored; we set the ownership and permissions on this directory appropriately. You will have to determine the location and ownership that is appropriate for your machine.

```
sensord --load-average \

  --rrd-file /var/log/sensord.rrd \

  --rrd-cgi /var/www/sensord \

  > /usr/lib/cgi-bin/sensord.cgi
chmod a+rx /usr/lib/cgi-bin/sensord.cgi
```

Here, we create a CGI script that will display sensor readings from the database. You must specify the location of the round-robin database, the location of the directory where the images should be stored, and whether you want the load average displayed. The --rrd-cgi command-line parameter causes sensord(8) to display a suitable CGI script on stdout and then to exit. You will need to write this script to the CGI bin directory of your Web server, and edit the script if the image directory you chose is not the `/sensord/' directory of your Web server.

Finally, you should be able to view your sensor readings from the URL `http://localhost/cgi-bin/sensord.cgi'.

## MODULES
It is expected that all required sensor modules are loaded prior to this daemon being started. This can either be achieved with a system specific module loading scheme (e.g., listing the required modules in the file `/etc/modules' under Debian) or with explicit modprobe(1) commands in an init script before loading the daemon.

For example, a `sensord' initialization script might contain (among others) the following commands:

```
# Sample init.d scriptlet
echo -n "Loading AMD756 module: "
modprobe i2c-amd756 || { echo Fail. ; exit 1 ; }
echo OK.
echo -n "Loading W83781D module: "
modprobe w83781d || { echo Fail. ; exit 1 ; }
echo OK.
echo -n "Starting sensord: "
daemon sensord
```

Ignore the platform-specific shell functions; the general idea should be fairly clear.

## ERRORS
Errors encountered by this daemon are logged to syslogd(8) after which the daemon will exit.

## BUGS
Round-robin database support doesn't cope with multiple sensor chips having duplicate sensor labels.

## FILES
/etc/sensors3.conf

/etc/sensors.conf

The system-wide libsensors(3) configuration file. See sensors.conf(5) for further details.

/etc/syslog.conf The system-wide syslog(3) / syslogd(8) configuration file. See syslog.conf(5) for further details.

## SEE ALSO
sensors.conf(5)

## AUTHORS
Sensord was written by Merlin Hughes <merlin@merlin.org>. Basics of round-robin databases were misappropriated from Mark D. Studebaker.


sensors-conf-convert

title: sensors-conf-convert(8)

summary: sensors configuration conversion

text:
# sensors-conf-convert(8)

## NAME
sensors-conf-convert - sensors configuration conversion

## SYNOPSIS
sensors-conf-convert < /etc/sensors.conf > /etc/sensors3.conf

## DESCRIPTION
The purpose of the sensors-conf-convert tool is to convert sensors.conf from the lm_sensors version 2 format to the lm_sensors version 3 format.

The old configuration file is read from the standard input and the new one is written to the standard output.

## SEE ALSO
sensors(1), libsensors(3)

## AUTHOR
Jean Delvare


package: lmbench

title: bw_file_rd(8)

summary: time the reading and summing of a file

text:
# bw_file_rd(8)

## NAME
bw_file_rd - time the reading and summing of a file

## SYNOPSIS
bw_file_rd [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] size file

## DESCRIPTION
bw_file_rd times the read of the specified file in 64KB blocks. Each block is summed up as a seried of 4 byte integers in an unrolled loop. Results are reported in megabytes read per second.

The data is not accessed in the user program; the benchmark relies on the operating systems read interface to have actually moved the data. Systems that implement page flipping may fool this benchmark.

The benchmark is intended to be used on a file that is in memory, i.e., the benchmark is a reread benchmark. Other file benchmarking can be done with lmdd(8).

The size specification may end with ``k'' or ``m'' to mean kilobytes (* 1024) or megabytes (* 1024 * 1024).

## OUTPUT
Output format is "%0.2f %.2f\n", megabytes, megabytes_per_second, i.e.,

8.00 25.33

## MEMORY UTILIZATION
This benchmark can move up to three times the requested memory. Most Unix systems implement the read system call as a bcopy from kernel space to user space. Bcopy will use 2-3 times as much memory bandwidth: there is one read from the source and a write to the destionation. The write usually results in a cache line read and then a write back of the cache line at some later point. Memory utilization might be reduced by 1/3 if the processor architecture implemented ``load cache line'' and ``store cache line'' instructions (as well as ``getcachelinesize'').

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: bw_mem(8)

summary: time memory bandwidth

text:
# bw_mem(8)

## NAME
bw_mem - time memory bandwidth

## SYNOPSIS
bw_mem_cp [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] size rd|wr|rdwr|cp|fwr|frd|bzero|bcopy [align]

## DESCRIPTION
bw_mem allocates twice the specified amount of memory, zeros it, and then times the copying of the first half to the second half. Results are reported in megabytes moved per second.

The size specification may end with ``k'' or ``m'' to mean kilobytes (* 1024) or megabytes (* 1024 * 1024).

## OUTPUT
Output format is "%0.2f %.2f\n", megabytes, megabytes_per_second, i.e.,

8.00 25.33

There are nine different memory benchmarks in bw_mem. They each measure slightly different methods for reading, writing or copying data.

rd

measures the time to read data into the processor. It computes the sum of an array of integer values. It accesses every fourth word.

wr

measures the time to write data to memory. It assigns a constant value to each memory of an array of integer values. It accesses every fourth word.

rdwr

measures the time to read data into memory and then write data to the same memory location. For each element in an array it adds the current value to a running sum before assigning a new (constant) value to the element. It accesses every fourth word.

cp

measures the time to copy data from one location to another. It does an array copy: dest[i] = source[i]. It accesses every fourth word.

frd

measures the time to read data into the processor. It computes the sum of an array of integer values.

fwr

measures the time to write data to memory. It assigns a constant value to each memory of an array of integer values.

fcp

measures the time to copy data from one location to another. It does an array copy: dest[i] = source[i].

bzero

measures how fast the system can bzero memory.

bcopy

measures how fast the system can bcopy data.

## MEMORY UTILIZATION
This benchmark can move up to three times the requested memory. Bcopy will use 2-3 times as much memory bandwidth: there is one read from the source and a write to the destionation. The write usually results in a cache line read and then a write back of the cache line at some later point. Memory utilization might be reduced by 1/3 if the processor architecture implemented ``load cache line'' and ``store cache line'' instructions (as well as ``getcachelinesize'').

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: bw_mem_rd(8)

summary: time memory read rate (with overhead)

text:
# bw_mem_rd(8)

## NAME
bw_mem_rd - time memory read rate (with overhead)

## SYNOPSIS
bw_mem_rd size

## DESCRIPTION
bw_mem_rd allocates the specified amount of memory, zeros it, and then times the reading of that memory as a series of integer loads and adds. Each four byte integer is loaded and added to accumulator.

The size specification may end with ``k'' or ``m'' to mean kilobytes (* 1024) or megabytes (* 1024 * 1024).

## OUTPUT
Output format is "%0.2f %.2f\n", megabytes, megabytes_per_second, i.e.,

8.00 25.33

## MEMORY UTILIZATION
This benchmark should move approximately the reported amount of memory.

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).


title: bw_mmap_rd(8)

summary: time the reading and summing of a file

text:
# bw_mmap_rd(8)

## NAME
bw_mmap_rd - time the reading and summing of a file

## SYNOPSIS
bw_mmap_rd [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] size file

## DESCRIPTION
bw_mmap_rd creates a memory mapping to the file and then reads the mapping in an unrolled loop similar to that used in bw_mem_rd(8). The benchmark is intended to be used on a file that is in memory, i.e., the benchmark is a reread benchmark. Other file benchmarking can be done with lmdd(8).

The size specification may end with ``k'' or ``m'' to mean kilobytes (* 1024) or megabytes (* 1024 * 1024).

## OUTPUT
Output format is "%0.2f %.2f\n", megabytes, megabytes_per_second, i.e.,

8.00 25.33

## MEMORY UTILIZATION
This benchmark should move approximately the reported amount of memory.

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: bw_pipe(8)

summary: time data movement through pipes

text:
# bw_pipe(8)

## NAME
bw_pipe - time data movement through pipes

## SYNOPSIS
bw_pipe [ -m <message size> ] [ -M <total bytes> ] [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ]

## DESCRIPTION
bw_pipe creates a Unix pipe between two processes and moves total bytes through the pipe in message size chunks (note that pipes are typically sized smaller than that). The default total bytes is 10MB and the default message size is 64KB.

## OUTPUT
Output format is "Pipe bandwidth: %0.2f MB/sec\n", megabytes_per_second, i.e.,

Pipe bandwidth: 4.87 MB/sec

## MEMORY UTILIZATION
This benchmark can move up to six times the requested memory per process. There are two processes, the sender and the receiver. Most Unix systems implement the read/write system calls as a bcopy from/to kernel space to/from user space. Bcopy will use 2-3 times as much memory bandwidth: there is one read from the source and a write to the destionation. The write usually results in a cache line read and then a write back of the cache line at some later point. Memory utilization might be reduced by 1/3 if the processor architecture implemented "load cache line" and "store cache line" instructions (as well as getcachelinesize).

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: bw_tcp(8)

text:
# bw_tcp(8)

## NAME
bw_tcp - time data movement through TCP/IP sockets

## SYNOPSIS
bw_tcp [ -m <message size> ] [ -M <total bytes> ] [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] server

bw_tcp -s

bw_tcp -S <server>

## DESCRIPTION
bw_tcp is a client/server program that moves data over a TCP/IP socket. Nothing is done with the data on either side; total bytes of data is moved in message size chunks.

bw_tcp has three forms of usage: as a server (-s), as a client (bw_tcp localhost), and as a shutdown (bw_tcp -S localhost).

The default amount of data is 10MB. The client form may specify a different amount of data. Specifications may end with ``k'' or ``m'' to mean kilobytes (* 1024) or megabytes (* 1024 * 1024).

## OUTPUT
Output format is Socket bandwidth using localhost: 2.32 MB/sec

## MEMORY UTILIZATION
This benchmark can move up to six times the requested memory per process when run through the loopback device. There are two processes, the sender and the receiver. Most Unix systems implement the read/write system calls as a bcopy from/to kernel space to/from user space. Bcopy will use 2-3 times as much memory bandwidth: there is one read from the source and a write to the destionation. The write usually results in a cache line read and then a write back of the cache line at some later point. Memory utilization might be reduced by 1/3 if the processor architecture implemented "load cache line" and "store cache line" instructions (as well as getcachelinesize).

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation and Silicon Graphics, Inc.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: bw_unix(8)

summary: UNIX pipe bandwidth

text:
# bw_unix(8)

## NAME
bw_unix - UNIX pipe bandwidth

## SYNOPSIS
bw_unix [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] size

## DESCRIPTION
bw_unix creates a pipe and forks a child process which keeps writing data to the pipe as fast as it can. The benchmark measures how fast the parent process can read the data in size-byte chunks from the pipe. Nothing is done with the data in either the parent (reader) or child (writer) processes.

The size specification may end with ``k'' or ``m'' to mean kilobytes (* 1024) or megabytes (* 1024 * 1024).

## OUTPUT
Output format is "%0.2f %.2f\n", megabytes, megabytes_per_second, i.e.,

8.00 25.33

## MEMORY UTILIZATION
This benchmark should move approximately the reported amount of memory.

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


cache

title: cache(8)

summary: cache parameters

text:
# cache(8)

## NAME
cache - cache parameters

## SYNOPSIS
cache [ -L <line size> ] [ -M <len> ] [ -W <warmups> ] [ -N <repetitions> ]

## DESCRIPTION
cache tries to determine the characteristics of the memory hierarchy. It attempts to determine the number of caches, the size of each cache, the line size for each cache, and the available memory parallelism at each level in the memory hierarchy. The largest amount of memory it will examine is len bytes.

cache first attempts to determine the number and size of caches by measuring the memory latency for various memory sizes. Once it has identified the various caches it then measures the latency, parallelism, and line size for each cache. Unfortunately, determining the cache size merely from latency is exceedingly difficult due to variations in cache replacement and prefetching strategies.

## BUGS
cache is an experimental benchmark and is known to fail on many processors. In particular there are a large number of machines with weird caching behavior that confuse cache and prevent it from accurately determining the number and size of the various caches.

## SEE ALSO
lmbench(8), line(8), tlb(8), par_mem(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lat_connect(8)

text:
# lat_connect(8)

## NAME
lat_connect - measure interprocess connection latency via TCP/IP

## SYNOPSIS
lat_connect -s

lat_connect [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] hostname

lat_connect -S hostname

## DESCRIPTION
lat_connect is a client/server program that measures interprocess connection latencies. The benchmark times the creation and connection of an AF_INET (aka TCP/IP) socket to a remote server. Care is take that the connection time does not include any other overhead, such as the gethostbyname() or remote port lookups since these add more overhead than the connection establishment itself.

lat_connect has three forms of usage: as a server (-s), as a client (lat_connect localhost), and as a shutdown (lat_connect -S localhost).

## OUTPUT
The reported time is in microseconds per connection. Output format is like so

TCP/IP connection cost to localhost: 1006 microseconds

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lat_ctx(8)

summary: context switching benchmark

text:
# lat_ctx(8)

## NAME
lat_ctx - context switching benchmark

## SYNOPSIS
lat_ctx [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] [ -s <size_in_kbytes> ] #procs [ #procs ... ]

## DESCRIPTION
lat_ctx measures context switching time for any reasonable number of processes of any reasonable size. The processes are connected in a ring of Unix pipes. Each process reads a token from its pipe, possibly does some work, and then writes the token to the next process.

Processes may vary in number. Smaller numbers of processes result in faster context switches. More than 20 processes is not supported.

Processes may vary in size. A size of zero is the baseline process that does nothing except pass the token on to the next process. A process size of greater than zero means that the process does some work before passing on the token. The work is simulated as the summing up of an array of the specified size. The summing is an unrolled loop of about a 2.7 thousand instructions.

The effect is that both the data and the instruction cache get polluted by some amount before the token is passed on. The data cache gets polluted by approximately the process ``size''. The instruction cache gets polluted by a constant amount, approximately 2.7 thousand instructions.

The pollution of the caches results in larger context switching times for the larger processes. This may be confusing because the benchmark takes pains to measure only the context switch time, not including the overhead of doing the work. The subtle point is that the overhead is measured using hot caches. As the number and size of the processes increases, the caches are more and more polluted until the set of processes do not fit. The context switch times go up because a context switch is defined as the switch time plus the time it takes to restore all of the process state, including cache state. This means that the switch includes the time for the cache misses on larger processes.

## OUTPUT
Output format is intended as input to xgraph or some similar program. The format is multi line, the first line is a title that specifies the size and non-context switching overhead of the test. Each subsequent line is a pair of numbers that indicates the number of processes and the cost of a context switch. The overhead and the context switch times are in micro second units. The numbers below are for a SPARCstation 2.

```
"size=0 ovr=179
2 71
4 104
8 134
16 333
20 438
```

## BUGS
The numbers produced by this benchmark are somewhat inaccurate; they vary by about 10 to 15% from run to run. A series of runs may be done and the lowest numbers reported. The lower the number the more accurate the results.

The reasons for the inaccuracies are possibly interaction between the VM system and the processor caches. It is possible that sometimes the benchmark processes are laid out in memory such that there are fewer TLB/cache conflicts than other times. This is pure speculation on our part.

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lat_fcntl(8)

summary: fcntl file locking benchmark

text:
# lat_fcntl(8)

## NAME
lat_fcntl - fcntl file locking benchmark

## SYNOPSIS
lat_ctx [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ]

## DESCRIPTION
lat_fcntl is a client/server program that measures file locking latencies. The benchmark alternately locks and unlocks files so that only one of the client or server is running at a time, similar to ``hot potato'' message passing benchmarks. No other work is done in the processes.

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8), lat_fifo(8), lat_tcp(8), lat_udp(8), lat_unix(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lat_fifo(8)

summary: FIFO benchmark

text:
# lat_fifo(8)

## NAME
lat_fifo - FIFO benchmark

## SYNOPSIS
lat_ctx [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ]

## DESCRIPTION
lat_fifo is a client/server program that measures interprocess communication latencies. The benchmark passes a message back and forth between the two processes (this sort of benchmark is frequently referred to as a ``hot potato'' benchmark). No other work is done in the processes. The message is passed back and forth using FIFOs.

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8), lat_fcntl(8), lat_tcp(8), lat_udp(8), lat_unix(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lat_fs(8)

text:
# lat_fs(8)

## NAME
lat_fs - measure file system create/delete performance

## SYNOPSIS
lat_fs [ dir ]

## DESCRIPTION
lat_fs is a program that creates a number of small files in the current working directory and then removes the files. Both the creation and removal of the files is timed.

## OPTIONS
If dir is specified, lat_fs will change to that directory first and do the creates and deletes there. Otherwise the creates and deletes are done in $PWD.

## OUTPUT
The results are in terms of creates per second and deletes per second as a function of file size. The output is in 4 column form and is the size of the file, the number created, the creations per second, and the removals per second. Output format looks like:

```
0k      500     1304    2740
1k      500     904     1663
4k      500     861     1647
10k     500     674     1516
```

## SEE ALSO
lmbench(8).


title: lat_http(8)

summary: fcntl file locking benchmark

text:
# lat_http(8)

## NAME
lat_fcntl - fcntl file locking benchmark

## SYNOPSIS
lat_ctx [ -d ] [ -e ] [ -S ] serverhost [ port ]

## DESCRIPTION
lat_http is a client/server program that measures simple http transaction latencies. It has its own HTTP server, and it is meant to simply measure the minimum overall costs of simple HTTP ``GET'' transactions. It does not measure the performance of third-party HTTP servers.

The client simply makes a series of HTTP GET requests for files. The files are a fixed set of files included with the benchmark. No special care was made to ensure that the file sizes match and predetermined distribution.

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8), lat_connect(8), lat_tcp(8), lat_sig(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lat_mem_rd(8)

summary: memory read latency benchmark

text:
# lat_mem_rd(8)

## NAME
lat_mem_rd - memory read latency benchmark

## SYNOPSIS
lat_mem_rd [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] size_in_megabytes stride [ stride stride... ]

## DESCRIPTION
lat_mem_rd measures memory read latency for varying memory sizes and strides. The results are reported in nanoseconds per load and have been verified accurate to within a few nanoseconds on an SGI Indy.

The entire memory hierarchy is measured, including onboard cache latency and size, external cache latency and size, main memory latency, and TLB miss latency.

Only data accesses are measured; the instruction cache is not measured.

The benchmark runs as two nested loops. The outer loop is the stride size. The inner loop is the array size. For each array size, the benchmark creates a ring of pointers that point backward one stride. Traversing the array is done by

p = (char **)*p;

in a for loop (the over head of the for loop is not significant; the loop is an unrolled loop 100 loads long).

The size of the array varies from 512 bytes to (typically) eight megabytes. For the small sizes, the cache will have an effect, and the loads will be much faster. This becomes much more apparent when the data is plotted.

Since this benchmark uses fixed-stride offsets in the pointer chain, it may be vulnerable to smart, stride-sensitive cache prefetching policies. Older machines were typically able to prefetch for sequential access patterns, and some were able to prefetch for strided forward access patterns, but only a few could prefetch for backward strided patterns. These capabilities are becoming more widespread in newer processors.

## OUTPUT
Output format is intended as input to xgraph or some similar program (we use a perl script that produces pic input). There is a set of data produced for each stride. The data set title is the stride size and the data points are the array size in megabytes (floating point value) and the load latency over all points in that array.

## INTERPRETING THE OUTPUT
The output is best examined in a graph where you typically get a graph that has four plateaus. The graph should plotted in log base 2 of the array size on the X axis and the latency on the Y axis. Each stride is then plotted as a curve. The plateaus that appear correspond to the onboard cache (if present), external cache (if present), main memory latency, and TLB miss latency.

As a rough guide, you may be able to extract the latencies of the various parts as follows, but you should really look at the graphs, since these rules of thumb do not always work (some systems do not have onboard cache, for example).

onboard cache

Try stride of 128 and array size of .00098.

external cache

Try stride of 128 and array size of .125.

main memory

Try stride of 128 and array size of 8.

TLB miss

Try the largest stride and the largest array.

## BUGS
This program is dependent on the correct operation of mhz(8). If you are getting numbers that seem off, check that mhz(8) is giving you a clock rate that you believe.

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8), tlb(8), cache(8), line(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lat_mmap(8)

text:
# lat_mmap(8)

## NAME
lat_mmap - costs of mmapping and unmmapping varying file sizes

## SYNOPSIS
lat_mmap [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] size file

## DESCRIPTION
lat_mmap times how fast a mapping can be made and unmade. This is useful because it is a fundemental part of processes that use SunOS style shared libraries (the libraries are mapped in at process start up time and unmapped at process exit).

The benchmark maps in and unmaps the first size bytes of the file repeatedly and reports the average time for one mapping/unmapping.

The size specification may end with ``k'' or ``m'' to mean kilobytes (* 1024) or megabytes (* 1024 * 1024).

## OUTPUT
Output format is "%0.2f %d\n", megabytes, usecs, i.e.,

8.00 1200

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lat_ops(8)

summary: basic CPU operation parallelism

text:
# lat_ops(8)

## NAME
lat_ops - basic CPU operation parallelism

## SYNOPSIS
lat_ops [ -W <warmups> ] [ -N <repetitions> ]

## DESCRIPTION
lat_ops measures the latency of basic CPU operations, such as integer ADD.

integer bit, add, mul, div, mod operations

maximum parallelism for integer XOR, ADD, MUL, DIV, MOD operations.

uint64 bit, add, mul, div, mod operations

maximum parallelism for uint64 XOR, ADD, MUL, DIV, MOD operations.

float add, mul, div operations

maximum parallelism for flot ADD, MUL, DIV operations.

double add, mul, div operations

maximum parallelism for flot ADD, MUL, DIV operations.

## BUGS
This benchmark is highly experimental and may sometimes (frequently?) give erroneous results.

## SEE ALSO
lmbench(8), par_ops(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lat_pagefault(8)

text:
# lat_pagefault(8)

## NAME
lat_pagefault - measure the cost of pagefaulting pages from a file

## SYNOPSIS
lat_pagefault [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] file [ file.... ]

## DESCRIPTION
lat_pagefault times how fast a page of a file can be faulted in. The file is flushed from (local) memory by using the msync() interface with the invalidate flag set. (Note that NFS does not send this over the wire so this makes for a handy way to measure the cost of going across the wire.)

The benchmark maps in the entire file and the access pages backwards using a stride of 256K kilobytes.

## OUTPUT
Output format is below; it prints the average cost of page faulting a page.

Pagefaults on <file>: <d> usecs

## BUGS
Using a stride of 256K may be a bad idea because SCSI controllers may have caches bigger than that.

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lat_pipe(8)

text:
# lat_pipe(8)

## NAME
lat_pipe - measure interprocess communication latency through pipes

## SYNOPSIS
lat_pipe [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ]

## DESCRIPTION
lat_pipe uses two processes communicating through a Unix pipe to measure interprocess communication latencies. The benchmark passes a token back and forth between the two processes (this sort of benchmark is frequently referred to as a ``hot potato'' benchmark). No other work is done in the processes.

## OUTPUT
The reported time is in microseconds per round trip and includes the total time, i.e., the context switching overhead is includeded. Output format is like so

Pipe latency: 491 microseconds

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lat_proc(8)

summary: process creation tests

text:
# lat_proc(8)

## NAME
lat_proc - process creation tests

## SYNOPSIS
lat_proc [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] procedure|fork|exec|shell

## DESCRIPTION
lat_proc creates processes in three different forms, each more expensive than the last. The purposes is to measure the time that it takes to create a basic thread of control.

The forms are listed and described below:

Process fork+exit

The time it takes to split a process into two (nearly) identical copies and have one exit. This is how new processes are created but is not very useful since both processes are doing the same thing.

Process fork+execve

The time it takes to create a new process and have that new process run a new program. This is the inner loop of all shells (command interpreters).

Process fork+/bin/sh -c

The time it takes to create a new process and have that new process run a new program by asking the system shell to find that program and run it. This is how the C library interface called system is implemented. It is the most general and the most expensive.

## OUTPUT
Output is in microseconds per operation like so:

```
Process fork+exit: 6054 microseconds
Process fork+execve: 11212 microseconds
Process fork+/bin/sh -c: 44346 microseconds
```

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lat_rpc(8)

text:
# lat_rpc(8)

## NAME
lat_rpc - measure interprocess communication latency via Sun RPC

## SYNOPSIS
lat_rpc -s

lat_rpc [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] [ -p tcp|udp ] hostname [ udp|tcp ]

lat_rpc -S hostname

## DESCRIPTION
lat_rpc is a client/server program that measures interprocess communication latencies. The benchmark passes a token back and forth between the two processes (this sort of benchmark is frequently referred to as a ``hot potato'' benchmark). No other work is done in the processes.

This benchmark may be compared to the TCP and UDP forms of the same benchmark to accurately see the cost of using RPC versus the cost of using plain old TCP or UDP sockets. It is worth noting that the RPC form is passing back and forth a single byte, not some long complicated record.

lat_rpc has three forms of usage: as a server (-s), as a client (lat_rpc localhost), and as a shutdown (lat_rpc -S localhost).

The client form may specify the protocol over which the RPCs are performed. The default is to measure performance for both udp and tcp.

## OUTPUT
The reported time is in microseconds per round trip and includes the total time, i.e., the context switching overhead is includeded. Output format is like so

RPC/udp latency using localhost: 1344 microseconds

RPC/tcp latency using localhost: 2089 microseconds

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lat_select(8)

summary: select benchmark

text:
# lat_select(8)

## NAME
lat_select - select benchmark

## SYNOPSIS
lat_ctx [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] [ n ]

## DESCRIPTION
lat_select measures the time to do a select on n file descriptors.

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lat_sig(8)

summary: select benchmark

text:
# lat_sig(8)

## NAME
lat_sig - select benchmark

## SYNOPSIS
lat_ctx [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] install|catch|prot [ file ]

## DESCRIPTION
lat_sig measures the time to install and catch signals. It can also measure the time to catch a protection fault.

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lat_syscall(8)

text:
# lat_syscall(8)

## NAME
lat_syscall - time simple entry into the operating system

## SYNOPSIS
lat_syscall [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] null|read|write|stat|fstat|open [ file ]

## DESCRIPTION
null

measures how long it takes to do getppid(). We chose getppid() because in all UNIX variants we are aware of, it requires a round-trip to/from kernel space and the actual work required inside the kernel is small and bounded.

read

measures how long it takes to read one byte from /dev/zero. Note that some operating systems do not support /dev/zero.

write

times how long it takes to write one byte to /dev/null. This is useful as a lower bound cost on anything that has to interact with the operating system.

stat

measures how long it takes to stat() a file whose inode is already cached.

fstat

measures how long it takes to fstat() an open file whose inode is already cached.

open

measures how long it takes to open() and then close() a file.

## OUTPUT
Output format is

Null syscall: 67 microseconds

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lat_tcp(8)

text:
# lat_tcp(8)

## NAME
lat_tcp - measure interprocess communication latency via TCP/IP

## SYNOPSIS
lat_tcp -s

lat_tcp [ -m <message size> ] [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] hostname

lat_tcp -S hostname

## DESCRIPTION
lat_tcp is a client/server program that measures interprocess communication latencies. The benchmark passes a message back and forth between the two processes (this sort of benchmark is frequently referred to as a ``hot potato'' benchmark). No other work is done in the processes.

lat_tcp has three forms of usage: as a server (-s), as a client (lat_tcp localhost), and as a shutdown (lat_tcp -S localhost).

## OUTPUT
The reported time is in microseconds per round trip and includes the total time, i.e., the context switching overhead is includeded. Output format is like so

TCP latency using localhost: 700 microseconds

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8), lat_fcntl(8), lat_fifo(8), lat_tcp(8), lat_udp(8), lat_unix(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lat_udp(8)

text:
# lat_udp(8)

## NAME
lat_udp - measure interprocess communication latency via UDP/IP

## SYNOPSIS
lat_udp -s

lat_udp [ -m <message size> ] [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] hostname

lat_udp -S hostname

## DESCRIPTION
lat_udp is a client/server program that measures interprocess communication latencies. The benchmark passes a message back and forth between the two processes (this sort of benchmark is frequently referred to as a ``hot potato'' benchmark). No other work is done in the processes.

lat_udp has three forms of usage: as a server (-s), as a client (lat_udp localhost), and as a shutdown (lat_udp -S localhost).

## OUTPUT
The reported time is in microseconds per round trip and includes the total time, i.e., the context switching overhead is included. Output format is like so

UDP latency using localhost: 650 microseconds

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8), lat_fcntl(8), lat_fifo(8), lat_tcp(8), lat_unix(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lat_unix(8)

text:
# lat_unix(8)

## NAME
lat_unix - measure interprocess communication latency via UNIX sockets

## SYNOPSIS
lat_unix [ -m <message size> ] [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ]

## DESCRIPTION
lat_unix is a client/server program that measures interprocess communication latencies. The benchmark passes a message back and forth between the two processes (this sort of benchmark is frequently referred to as a ``hot potato'' benchmark). No other work is done in the processes.

## OUTPUT
The reported time is in microseconds per round trip and includes the total time, i.e., the context switching overhead is includeded. Output format is like so

AF_UNIX sock stream latency: 700 microseconds

## ACKNOWLEDGEMENT
Funding for the development of this tool was provided by Sun Microsystems Computer Corporation.

## SEE ALSO
lmbench(8), lat_fcntl(8), lat_fifo(8), lat_tcp(8), lat_udp(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: lat_unix_connect(8)

text:
# lat_unix_connect(8)

## NAME
lat_unix_connect - measure interprocess connection latency via UNIX sockets

## SYNOPSIS
lat_unix_connect -s

lat_unix_connect [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ]

lat_unix_connect -S

## DESCRIPTION
lat_unix_connect is a client/server program that measures interprocess connection latencies. The benchmark times the creation and connection of an AF_UNIX socket to a local server.

lat_connect has three forms of usage: as a server (-s), as a client (lat_connect), and as a shutdown (lat_connect -S).

## OUTPUT
The reported time is in microseconds per connection. Output format is like so

UNIX connection cost: 1006 microseconds

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


line

title: line(8)

summary: cache line size

text:
# line(8)

## NAME
line - cache line size

## SYNOPSIS
line [ -M <len> ] [ -W <warmups> ] [ -N <repetitions> ]

## DESCRIPTION
line tries to determine the cache line size in bytes of the largest cache which is smaller than len bytes.

line creates pointer chains which access the first word on each cache line on a page (randomly meandering through all the lines in a page before jumping to the next page). It measures the average memory latency for a variety of line sizes, starting with a line size of one word. When it finds an increase in the average latency that is significantly larger than the latency for the smaller line size then it assumes that it has found the line size.

This algorithm works because for line sizes less than the true line size, at least two line cache lines fit in the space of a true cache line. Since that cache line will be accessed twice, the first access will cause an expensive cache miss, while the second access will be a cache hit. Once the line cache line is equal to the true cache line size, then all accesses will cause cache misses.

## BUGS
line is an experimental benchmark, but it seems to work well on most systems.

## SEE ALSO
lmbench(8), tlb(8), cache(8), par_mem(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


lmbench

title: lmbench(8)

summary: system benchmarks

text:
# lmbench(8)

## NAME
lmbench - system benchmarks

## DESCRIPTION
lmbench is a series of micro benchmarks intended to measure basic operating system and hardware system metrics. The benchmarks fall into three general classes: bandwidth, latency, and ``other''.

Most of the lmbench benchmarks use a standard timing harness described in timing(3) and have a few standard options: parallelism, warmup, and repetitions. Parallelism specifies the number of benchmark processes to run in parallel. This is primarily useful when measuring the performance of SMP or distributed computers and can be used to evaluate the system's performance scalability. Warmup is the number of minimum number of microseconds the benchmark should execute the benchmarked capability before it begins measuring performance. Again this is primarily useful for SMP or distributed systems and it is intended to give the process scheduler time to "settle" and migrate processes to other processors. By measuring performance over various warmup periods, users may evaulate the scheduler's responsiveness. Repetitions is the number of measurements that the benchmark should take. This allows lmbench to provide greater or lesser statistical strength to the results it reports. The default number of repetitions is 11.

## BANDWIDTH MEASUREMENTS
Data movement is fundemental to the performance on most computer systems. The bandwidth measurements are intended to show how the system can move data. The results of the bandwidth metrics can be compared but care must be taken to understand what it is that is being compared. The bandwidth benchmarks can be reduced to two main components: operating system overhead and memory speeds. The bandwidth benchmarks report their results as megabytes moved per second but please note that the data moved is not necessarily the same as the memory bandwidth used to move the data. Consult the individual man pages for more information.

Each of the bandwidth benchmarks is listed below with a brief overview of the intent of the benchmark.

bw_file_rd

reading and summing of a file via the read(2) interface.

bw_mem_cp

memory copy.

bw_mem_rd

memory reading and summing.

bw_mem_wr

memory writing.

bw_mmap_rd

reading and summing of a file via the memory mapping mmap(2) interface.

bw_pipe

reading of data via a pipe.

bw_tcp

reading of data via a TCP/IP socket.

bw_unix

reading data from a UNIX socket.

## LATENCY MEASUREMENTS
Control messages are also fundemental to the performance on most computer systems. The latency measurements are intended to show how fast a system can be told to do some operation. The results of the latency metrics can be compared to each other for the most part. In particular, the pipe, rpc, tcp, and udp transactions are all identical benchmarks carried out over different system abstractions.

Latency numbers here should mostly be in microseconds per operation.

lat_connect

the time it takes to establish a TCP/IP connection.

lat_ctx

context switching; the number and size of processes is varied.

lat_fcntl

fcntl file locking.

lat_fifo

``hot potato'' transaction through a UNIX FIFO.

lat_fs

creating and deleting small files.

lat_pagefault

the time it takes to fault in a page from a file.

lat_mem_rd

memory read latency (accurate to the ~2-5 nanosecond range, reported in nanoseconds).

lat_mmap

time to set up a memory mapping.

lat_ops

basic processor operations, such as integer XOR, ADD, SUB, MUL, DIV, and MOD, and float ADD, MUL, DIV, and double ADD, MUL, DIV.

lat_pipe

``hot potato'' transaction through a Unix pipe.

lat_proc

process creation times (various sorts).

lat_rpc

``hot potato'' transaction through Sun RPC over UDP or TCP.

lat_select

select latency

lat_sig

signal installation and catch latencies. Also protection fault signal latency.

lat_syscall

non trivial entry into the system.

lat_tcp

``hot potato'' transaction through TCP.

lat_udp

``hot potato'' transaction through UDP.

lat_unix

``hot potato'' transaction through UNIX sockets.

lat_unix_connect

the time it takes to establish a UNIX socket connection.

## OTHER MEASUREMENTS
mhz

processor cycle time

tlb

TLB size and TLB miss latency

line

cache line size (in bytes)

cache

cache statistics, such as line size, cache sizes, memory parallelism.

stream

John McCalpin's stream benchmark

par_mem

memory subsystem parallelism. How many requests can the memory subsystem service in parallel, which may depend on the location of the data in the memory hierarchy.

par_ops

basic processor operation parallelism.

## SEE ALSO
bargraph(1), graph(1), lmbench(3), results(3), timing(3), bw_file_rd(8), bw_mem_cp(8), bw_mem_wr(8), bw_mmap_rd(8), bw_pipe(8), bw_tcp(8), bw_unix(8), lat_connect(8), lat_ctx(8), lat_fcntl(8), lat_fifo(8), lat_fs(8), lat_http(8), lat_mem_rd(8), lat_mmap(8), lat_ops(8), lat_pagefault(8), lat_pipe(8), lat_proc(8), lat_rpc(8), lat_select(8), lat_sig(8), lat_syscall(8), lat_tcp(8), lat_udp(8), lmdd(8), par_ops(8), par_mem(8), mhz(8), tlb(8), line(8), cache(8), stream(8)

## ACKNOWLEDGEMENT
Funding for the development of these tools was provided by Sun Microsystems Computer Corporation.

A large number of people have contributed to the testing and development of lmbench.

## COPYING
The benchmarking code is distributed under the GPL with additional restrictions, see the COPYING file.

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


lmdd

title: lmdd(8)

text:
# lmdd(8)

## NAME
lmdd - move io for performance and debugging tests

## SYNOPSIS
lmdd [ option=value ] ...

## DESCRIPTION
lmdd copies a specified input file to a specified output with possible conversions. This program is primarily useful for timing I/O since it prints out the timing statistics after completing.

## OPTIONS
if=name

Input file is taken from name; internal is the default. internal is a special file that acts like Sun's /dev/zero, i.e., it provides a buffer of zeros without doing a system call to get them. The following file names are taken to mean the standard input: -, 0, or stdin.

of=name

Output file is taken from name; internal is the default. internal is a special file that acts like /dev/null, without doing a system call to get rid of the data. The following file names are taken to mean the standard output: -, 1, or stdout.

The following file names are taken to mean the standard error: 2, or stderr.

bs=n

Input and output block size n bytes (default 8192). Note that this is different from dd(1), it has a 512 byte default. Also note that the block size can be followed by 'k' or 'm' to indicate kilo bytes (*1024) or megabytes (*1024*1024), respectively.

ipat=n

If n is non zero, expect a known pattern in the file (see opat). Mismatches will be displayed as "ERROR: off=%d want=%x got=%x". The pattern is a sequence of 4 byte integers with the first 0, second 1, and so on. The default is not to check for the pattern.

opat=n

If n is non zero, generate a known pattern on the output stream. Used for debugging file system correctness. The default is not to generate the pattern.

mismatch=n

If n is non zero, stop at the first mismatched value. Used with ipat.

skip=n

Skip n input blocks before starting copy.

fsync=n

If n is non-zero, call fsync(2) on the output file before exiting or printing timing statistics.

sync=n

If n is non-zero, call sync(2) before exiting or printing timing statistics.

rand=n

This argument, by default off, turns on random behavior. The argument is not a flag, it is a size, that size is used as the upper bound for the seeks. Also note that the block size can be followed by 'k' or 'm' to indicate kilo bytes (*1024) or megabytes (*1024*1024),

flush=n

If n is non-zero and mmap(2) is available, call msync(2) to invalidate the output file. This flushes the file to disk so that you don't have unmount/mount. It is not as good as mount/unmount because it just flushes file pages - it misses the indirect blocks which are still cached. Not supported on all systems, compile time option.

rusage=n

If n is non-zero, print rusage statistics as well as timing statistics. Not supported on all systems, compile time option.

count=n

Copy only n input records.

## EXAMPLES
This is the most common usage, the intent is to measure disk performance. The disk is a spare partition mounted on /spare.

```
# mount /spare
# lmdd if=internal of=/spare/XXX count=1000 fsync=1
7.81 MB in 3.78 seconds (2.0676 MB/sec)
: Flush cache
# umount /spare
# mount /spare
# lmdd if=/spare/XXX of=internal
7.81 MB in 2.83 seconds (2.7611 MB/sec)
```

## AUTHOR
Larry McVoy, lm@sun.com


mhz

title: mhz(8)

summary: calulate processor clock rate

text:
# mhz(8)

## NAME
mhz - calulate processor clock rate

## SYNOPSIS
mhz [-c]

## DESCRIPTION
mhz calculates the processor clock rate and megahertz. It uses an unrolled, interlocked loop of adds or shifts. So far, superscalarness has been defeated on the tested processors (SuperSPARC, RIOS, Alpha).

## OUTPUT
Output format is either just the clock rate as a float (-c) or more verbose

39.80 Mhz, 25 nanosec clock

mhz is described more completely in ``mhz: Anatomy of a microbenchmark'' in Proceedings of 1998 USENIX Annual Technical Conference , June 1998.

## SEE ALSO
lmbench(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: par_mem(8)

summary: memory parallelism benchmark

text:
# par_mem(8)

## NAME
par_mem - memory parallelism benchmark

## SYNOPSIS
par_mem [ -L <line size> ] [ -M <len> ] [ -W <warmups> ] [ -N <repetitions> ]

## DESCRIPTION
par_mem measures the available parallelism in the memory hierarchy, up to len bytes. Modern processors can often service multiple memory requests in parallel, while older processors typically blocked on LOAD instructions and had no available parallelism (other than that provided by cache prefetching). par_mem measures the available parallelism at a variety of points, since the available parallelism is often a function of the data location in the memory hierarchy.

In order to measure the available parallelism par_mem conducts a variety of experiments at each memory size; one for each level of parallelism. It builds a pointer chain of the desired length. It then creates an array of pointers which point to chain entries which are evenly spaced across the chain. Then it starts running the pointers forward through the chain in parallel. It can then measure the average memory latency for each level of parallelism, and the available parallelism is the minimum average memory latency for parallelism 1 divided by the average memory latency across all levels of available parallelism.

For example, the inner loop which measures parallelism 2 would look something like:

for (i = 0; i < N; ++i) { p0 = (char **)*p0; p1 = (char **)*p1; }

in a for loop (the overhead of the for loop is not significant; the loop is an unrolled loop 100 loads long). In this case, if the hardware can process two LOAD operations in parallel, then the overall latency of the loop should be equivalent to that of a single pointer chain, so the measured parallelism would be roughly two. If, however, the hardware can only process a single LOAD operation at once, or if there is (significant) resource contention between the two LOAD operations, then the loop will be much slower than a loop with a single pointer chain, so the measured parallelism will be less than two, and probably no smaller than one.

## OUTPUT
Output format is intended as input to xgraph or some similar program (we use a perl script that produces pic input). There is a set of data produced for each stride. The data set title is the stride size and the data points are the array size in megabytes (floating point value) and the load latency over all points in that array.

## SEE ALSO
lmbench(8), line(8), cache(8), tlb(8), par_ops(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


title: par_ops(8)

summary: basic CPU operation parallelism

text:
# par_ops(8)

## NAME
par_ops - basic CPU operation parallelism

## SYNOPSIS
par_ops [ -W <warmups> ] [ -N <repetitions> ]

## DESCRIPTION
par_ops measures the available parallelism for basic CPU operations, such as integer ADD. Results are reported as the average operation latency divided by the minimum average operation latency across all levels of parallelism.

integer bit, add, mul, div, mod operations;

maximum parallelism for integer XOR, ADD, MUL, DIV, MOD operations.

uint64 bit, add, mul, div, mod operations;

maximum parallelism for uint64 XOR, ADD, MUL, DIV, MOD operations.

float add, mul, div operations;

maximum parallelism for flot ADD, MUL, DIV operations.

double add, mul, div operations;

maximum parallelism for flot ADD, MUL, DIV operations.

## BUGS
This benchmark is highly experimental and may sometimes (frequently?) give erroneous results.

## SEE ALSO
lmbench(8), lat_ops(8), par_mem(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


stream

title: stream(8)

summary: John McCalpin's STREAM benchmark

text:
# stream(8)

## NAME
stream - John McCalpin's STREAM benchmark

## SYNOPSIS
stream [ -M <len> ] [ -W <warmups> ] [ -N <repetitions> ]

## DESCRIPTION
stream mimics John McCalpin's STREAM benchmark. It measures memory bandwidth.

## BUGS
stream is an experimental benchmark, but it seems to work well on most systems.

## SEE ALSO
lmbench(8), bw_mem(8), line(8), tlb(8), cache(8), par_mem(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


tlb

title: tlb(8)

summary: TLB size and latency benchmark

text:
# tlb(8)

## NAME
tlb - TLB size and latency benchmark

## SYNOPSIS
tlb [ -L <line size> ] [ -M <len> ] [ -W <warmups> ] [ -N <repetitions> ]

## DESCRIPTION
tlb tries to determine the size, in pages, of the TLB. The largest amount of memory it will examine is len bytes.

tlb compares the memory latency for two different pointer chains. The two chains occupy the same amount of cache space, but they stress the memory subsystem differently. The first chain accesses one word per page, while the second chain randomly jumps through all the lines on a page before jumping to the next page. When all of the pointers reside in the cache (which is the usual case), and all of the pages for the first chain reside in the TLB, then the average memory latencies should be identical. Assuming there is a fixed size TLB, then at some point the number of pages accessed by the first page will be larger than the TLB. At this point the average latency for each memory access for the first chain will be a cache hit plus some fraction of a TLB miss.

Once the TLB boundary is located tlb reports the TLB miss latency as the TLB latency for twice as many pages as the TLB can hold.

## BUGS
tlb is an experimental benchmark, but it seems to work well on most systems. However, if a processor has a TLB hierarchy tlb only finds the top level TLB.

## SEE ALSO
lmbench(8), line(8), cache(8), par_mem(8).

## AUTHOR
Carl Staelin and Larry McVoy

Comments, suggestions, and bug reports are always welcome.


logcheck

package: logcheck

title: logcheck(8)

text:
# logcheck(8)

## NAME
logcheck — program to scan system logs for interesting lines

## SYNOPSIS
logcheck [OPTIONS]

## DESCRIPTION
The logcheck program helps spot problems and security violations in your logfiles automatically and will send the results to you periodically in an e-mail. By default logcheck runs as an hourly cronjob just off the hour and after every reboot.

logcheck supports three level of filtering: "paranoid" is for high-security machines running as few services as possible. Don't use it if you can't handle its verbose messages. "server" is the default and contains rules for many different daemons. "workstation" is for sheltered machines and filters most of the messages. The ignore rules work in additive manner. "paranoid" rules are also included at level "server". "workstation" level includes both "paranoid" and "server" rules.

The messages reported are sorted into three layers, system events, security events and attack alerts. The verbosity of system events is controlled by which level you choose, paranoid, server or workstation. However, security events and attack alerts are not affected by this.

## EXAMPLES
logcheck can be invoked directly thanks to su(8) or sudo(8), which change the user ID. The following example checks the logfiles without updating the offset and outputs everything to STDOUT.

sudo -u logcheck logcheck -o -t

## OPTIONS
A summary of options is included below.

-c CFG

Overrule default configuration file.

-d

Debug mode.

-h

Show usage information.

-H

Use this hostname string in the subject of logcheck mail.

-l LOG

Run logfile through logcheck.

-L CFG

Overrule default logfiles list.

-m

Mail report to recipient.

-o

STDOUT mode, not sending mail.

-p

Set the report level to "paranoid".

-r DIR

Overrule default rules directory.

-R

Adds "Reboot:" to the email subject line.

-s

Set the report level to "server".

-S DIR

Overrule default state directory.

-t

Testing mode does not update offset.

-T

Do not remove the TMPDIR.

-u

Enable syslog-summary.

-v

Print current version.

-w

Set the report level to "workstation".

## FILES
/etc/logcheck/logcheck.conf is the main configuration file.

/etc/logcheck/logcheck.logfiles is the list of files to monitor.

/usr/share/doc/logcheck-database/README.logcheck-database.gz for hints on how to write, test and maintain rules.

## EXIT STATUS
0 upon success; 1 upon failure

## SEE ALSO
logtail(8)

## AUTHOR
logcheck is developed by Debian logcheck Team at alioth: http://alioth.debian.org/projects/logcheck/.

This manual page was written by Jon Middleton.


logkeys

package: logkeys

title: logkeys(8)

summary: a GNU/Linux keylogger that works!

text:
# logkeys(8)

## NAME
logkeys - a GNU/Linux keylogger that works!

## SYNOPSIS
logkeys -s [-m keymap | -u] [-o logfile] [-d device]

[--no-func-keys] [--no-timestamps]

[--post-http=URL] [--post-size=SIZE]

logkeys -k

logkeys [--export-keymap=keymap]

## DESCRIPTION
logkeys is a linux keylogger. It is no more advanced than other available linux keyloggers, notably lkl and uberkey, but is a bit newer, more up to date, it doesn't unreliably repeat keys and it shouldn't crash your X. All in all, it just seems to work. It relies on the event interface of Linux input subsystem (normally devices /dev/input/eventX).

Once set, it logs all common character and function keys, while also being fully aware of Shift and AltGr key modifiers. It tries to automatically determine the correct input device, and may in some cases also get the character keys mapping right.

Two helper setuid root programs are shipped with logkeys. llk, which runs etc/logkeys-start.sh script, and llkk, which runs etc/logkeys-kill.sh script. Because llk and llkk are installed setuid root, you can edit the two .sh scripts (mostly just logkeys-start.sh) to your preference, then issue logkeys via llk whenever you have to run it covertly (e.g. when you don't want to su to root or type sudo password).

## OPTIONS
Non-optional arguments are required for short options too.

-s, --start

Starts the keylogging daemon process.

-k, --kill

Terminates the running logkeys process.

-o, --output=logfile

Set ouput log file to logfile. If no -o option is provided, logkeys appends to /var/log/logkeys.log file. If logfile doesn't exist, logkeys creates the file with 600 permissions.

See also LOGFILE FORMAT section.

-m, --keymap=keymap

Use file keymap as input keymap for processing pressed keys.

This option works best if keymap is hand corrected file, which had been previously exported by --export-keymap.

See also KEYMAP FORMAT section.

-m and -u option are mutually exclusive.

-d, --device=device

Use device as keyboard input event device instead of /dev/input/eventX default.

You can determine the keyboard device to be used by examining /proc/bus/input/devices.

-u, --us-keymap

This option makes logkeys interpret keys as on standard US keyboard.

-u and -m option are mutually exclusive.

--export-keymap=keymap

This option makes logkeys export dynamic keymap as obtained from dumpkeys(1) to file keymap and then exit.

keymap can later be used with -m option to override automatic keymap "calculation", which may be wrong.

It is advised that you manually edit keymap and correct any mistakes as well as complete deficient entries. It is also advised that you use --export-keymap on a virtual terminal outside of X (/dev/ttyX).

See section KEYMAP FORMAT for exported keymap format.

--no-func-keys

This option makes logkeys log all and only character key presses (1, 2, ..., q, w, e, ..., a, s, d, f, ..., ", @, \, ...).

This option may be useful when correct keymap can reliably be expected (i.e. by providing it with -m option). Then only character keys are logged, influenced by Shift and AltGr modifiers.

--no-timestamps

When this option is set, logkeys doesn't prepend timestamp to each line of log file. Timestamps are only logged when logkeys starts and stops.

--post-size=SIZE

When log size reaches SIZE, the current log filename is appended .X, where X is ascending number (e.g. logfile.1).

When that happens, logkeys starts remote uploading process and all logfile.X files are uploaded as specified by --post-http or --post-irc options.

If --post-size is set, but no post method is set, then the logfile is only truncated when it reaches SIZE, renamed to logfile.X, and a new blank logfile is created for active logging.

If --post-size is not set, but post method is, then the default SIZE of 500 KB (500.000 B) is used.

If --post-size is not set, and neither is any post method, then logkeys appends to the single specified log file.

SIZE can be an integer bytesize, or an intger followed by K or M for kilobytes or megabytes, respectively.

--post-http=URL

This option tells logkeys to POST the log file to URL, where it is preferrably greeted by a (PHP) script.

The file is sent with header Content-Type: multipart/form-data as file, so it is accessible in PHP via $_FILES['file'] variable.

## FILES
/var/log/logkeys.log

When -o option is not used, logkeys appends to this default log file.

etc/logkeys-start.sh

Setuid root program llk runs this script. Edit the contents to suit your needs.

etc/logkeys-stop.sh

Setuid root program llkk runs this script. Default value should work well.

## LOGFILE FORMAT
Log files are UTF-8 encoded.

Each logging session is enclosed in "Logging started... [<timestamp>]" and "Logging stopped at <timestamp>" strings. Whenever Enter key (Return key) or Ctrl+C or Ctrl+D combination is pressed, a timestamp is appended on a new line (provided --no-timestamps is not in effect).

Timestamp format is "%F %T%z", which results in "YYYY-mm-dd HH:MM:SS+ZZZZ". Timestamp is separated from the logged keys by one '>' symbol.

All character key presses are logged as they appear. All function key presses are replaced with strings as obtained from keymap file, or as hardcoded when no keymap file is provided.

If a key is pressed down long enough so it repeats, it is logged only once and then "<#+DD>" is appended, which hints the key was repeated DD more times. The DD decimal figure is not to be relied on.

If a keypress results in keycode, which is not recognized (i.e. key not found on a standard US or Intl 105-key keyboard), then the string "<E-XX>" is appended, where XX is the received keycode in hexadecimal format. All new "WWW", "E-Mail", "Volume+", "Media", "Help", etc. keys will result in such error strings.

Using US keyboard layout, one example log file could look like:

Logging started ...

2009-12-11 09:58:17+0100 > llk

2009-12-11 09:58:20+0100 > sudo cp <RShift>~/foo.<Tab> /usr/bin

2009-12-11 09:58:26+0100 > <LShift>R00<LShift>T_p455\\/0rD

2009-12-11 09:58:39+0100 > <Up><Up><Home>sudo

2009-12-11 09:58:44+0100 > c<#+53><BckSp><#+34><LCtrl>c

2009-12-11 09:58:54+0100 > llkk

Logging stopped at 2009-12-11 09:58:54+0100

If the same log was obtained by a logkeys process invoked with --no-func-keys option, it would look like:

Logging started ...

2009-12-11 09:58:17+0100 > llk

2009-12-11 09:58:20+0100 > sudo cp ~/foo. /usr/bin

2009-12-11 09:58:26+0100 > R00T_p455\\/0rD

2009-12-11 09:58:39+0100 > sudo

2009-12-11 09:58:44+0100 > c<#+53>c

2009-12-11 09:58:54+0100 > llkk

Logging stopped at 2009-12-11 09:58:54+0100

Even when --no-func-keys is in effect, Space and Tab key presses are logged as a single space character.

## KEYMAP FORMAT
The keymap file is expected to be UTF-8 encoded.

Each line of file represents either one character key or one function key. The format specifies at least one and up to three space-delimited characters on character key lines (first without modifiers, optional second with Shift in action, optional third with AltGr in action), and up to 7 characters long string on function key lines.

First three lines in a Slovene keymap file look like:

<Esc>

1 ! ~

2 " ˇ

How does one know which lines belong to character keys and which lines to function keys?

Well, the easiest way is to use --export-keymap, and examine the exported keymap. Make sure you export in a virtual terminal (ttyX) and not in X as this way more keys could get exported correctly (don't ask me why).

Basically, --export-keymap ouputs 106 lines for 106 keys, even if some of those keys aren't located on your keyboard. Lines 1, 14, 15, 28, 29, 42, 54-83, 85-106 belong to function keys, all other lines (2-13, 16-27, 30-41, 43-53, 84) belong to character keys.

Line 57 is reserved for Space and it should always be ' '. Line 84 is reserved for the key just right to left Shift that is present on some international layouts. Other lines can be quite reliably determined by looking at one exported keymap. The keys generally follow the order of their appearance on the keyboard, top-to-bottom left-to-right.

If you create full and completely valid keymap for your particular language, please upload it to project website or send it to me by e-mail. Thanks.

## EXAMPLES
To print short help:

$ logkeys

To start logging to a custom log file with dynamically generated keymap:

$ logkeys --start --output /home/user/.secret/log

To start logging to default log file on a standard US keyboard:

$ logkeys --start --us-keymap

To export dynamically generated keymap to file:

$ logkeys --export-keymap my_keymap

To start logging to default log file with a custom keymap:

$ logkeys --start --keymap my_keymap

To use a custom event device (e.g. /dev/input/event4):

$ logkeys --start --device event4

To end running logkeys process:

$ logkeys --kill

After etc/logkeys-start.sh is updated to one's liking, helper programs bin/llk (start) and bin/llkk (kill) can be used as well.

## BUGS
logkeys relies on numeric output of dumpkeys(1), which keymaps(5) manual page specifically discourages as unportable.

Be nice and hope nothing breaks.

If you come across any bugs, please report them on project website, issues page:

http://code.google.com/p/logkeys/issues/

## AUTHOR
logkeys was written by Kernc <kerncece+logkeys@gmail.com> with much help from the community.

You can always obtain the latest version and information at project website: <http://code.google.com/p/logkeys/>.