atmarpd

title: atmarpd(8)

summary: ATMARP demon

text:
# atmarpd(8)

## NAME
atmarpd - ATMARP demon

## SYNOPSIS
atmarpd [-b] [-d] [-D directory] [-l logfile] [-m] [-n]

atmarpd -V

## DESCRIPTION
atmarpd implements the ATMARP protocol as specified in RFC1577 and RFC1755. Address resolution requests are sent from the kernel (using a comparably simple protocol) to the ATMARP demon, which then performs the dialog with the network.

atmarpd can operate as an ATMARP client and as an ATMARP server. If also supports the concurrent use of several IP over ATM interfaces.

atmarpd is configured from the command line using the atmarp program. Unless debugging is enabled, the ATMARP table is written after every change to the file /var/run/atmarpd.table (or to a file with the same name in a different directory, if the -D option is used).

Note that atmarpd disables support for SVCs if signaling is not available at start time, i.e. if atmsigd is not running.

## OPTIONS
-b

Run in background (i.e. in a forked child process) after initializing.

-d

Enables (lots of) debugging output. By default, atmarpd is comparably quiet.

-D dump_dir

Changes the directory where atmarpd writes its table (atmarpd.table). By default, /var/run is used.

-l logfile

Write diagnostic messages to the specified file instead of to standard error. The special name syslog is used to send diagnostics to the system logger.

-m

Enables merging of incoming calls if the address is known. An incoming connection on which no InARP reply has been received yet, but which originates from an ATM address for which an ATMARP entry already exists, is automatically added to that entry. This assumes that there is a 1:1 mapping between IP addresses and ATMARP addresses. By default, this assumption is not made, which frequently results in the setup of duplicate connections. Note that RFC1577 requires that an ATMARP server sends an InARP request on an incoming connection. Merging may therefore violate RFC1577 in this case.

-n

Prints addresses in numeric format only, i.e. no address to name translation is attempted.

-V

Prints the version number of atmarpd on standard output and exits.

## FILES
/var/run/atmarpd.table

ATMARP table

/proc/atm/arp

table of currently active IP over ATM VCs

## BUGS
atmarpd removes ATMARP entries from the kernel table while refreshing them.

## AUTHOR
Werner Almesberger, EPFL ICA <werner.almesberger@epfl.ch>

## SEE ALSO
atmarp(8), atmsigd(8)


atmdiag

package: linux-atm

title: atmdiag(8)

summary: show ATM device driver diagnostics

text:
# atmdiag(8)

## NAME
atmdiag - show ATM device driver diagnostics

## SYNOPSIS
atmdiag [-z] [interface...]

## DESCRIPTION
atmdiag shows statistic counters maintained by ATM device drivers. If one or more interface numbers are specified, the statistics of only these interfaces are shown. Otherwise, statistics of all interfaces are displayed.

The following counters are shown for each AAL:

TX_okay

number of successfully sent PDUs.

TX_err

number of PDUs not sent because of errors.

RX_okay

number of successfully received PDUs.

RX_err

number of PDUs discarded because of errors.

RX_drop

number of PDUs dropped because of lack of memory.

## OPTIONS
-z

zero all counters after showing them.

## AUTHOR
Werner Almesberger, EPFL ICA <Werner.Almesberger@epfl.ch>

## SEE ALSO
atmdump(8), sonetdiag(8)


atmdump

title: atmdump(8)

summary: capture or generate ATM cells

text:
# atmdump(8)

## NAME
atmdump - capture or generate ATM cells

## SYNOPSIS
atmdump [-i] [ -t type [-g gfc] [-c] ] [itf.]vpi.vci

## DESCRIPTION
atmdump captures or generates single ATM cells ("AAL0"). When capturing cells, a time stamp, the cell header contents, and a hex dump of the cell payload are shown. When sending cells, the payload type, the generic flow control (GFC), and the cell loss priority (CLP) can be set.

In both modes of operation, the interface number, the VPI, and the VCI have to be specified.

When sending, atmdump expects the cell payload on standard input. If only less than 48 bytes can be read, the remaining space is padded with zero bytes.

## OPTIONS
-i

displays timestamps as the interval since the last cell reception. By default, the absolute time is displayed. This options is ignored in transmit mode.

-t type

selects transmit mode and specifies the payload type. A list of valid payload type numbers can be obtained by invoking atmdump without any arguments.

-g gfc

specifies the value of the GFC field. gfc has to be in the range from 0 to 15, default is zero.

-c

sets the cell loss priority flag, indicating low priority. By default, CLP is not set.

## RESTRICTIONS
Some device drivers may not pass OAM cells transparently.

## AUTHOR
Werner Almesberger, EPFL ICA <Werner.Almesberger@epfl.ch>

## SEE ALSO
atmdiag(8), clip(8), sonetdiag(8)


atmloop

title: atmloop(8)

summary: get/set loopback mode of ATM interfaces

text:
# atmloop(8)

## NAME
atmloop - get/set loopback mode of ATM interfaces

## SYNOPSIS
atmloop -s [-l level] [-r level] [itf]

atmloop [itf]

atmloop -q [itf]

atmloop -V

## DESCRIPTION
atmloop sets or shows the current loopback settings of an ATM interface, and allows to query the loopback modes supported by the interface.

Some ATM cards can be configured to echo data back to the driver (local loopback) or to the network (remote loopback). The echoing may be done at several different levels:

aal

AAL PDUs

atm

ATM cells

digital

bits sent to or received from the line interface

analog

the analog signal

The levels supported by an interface can be queried with the -q option. If invoked without options, atmloop displays the current loopback settings.

## OPTIONS
-s

set loopback mode. Followed by either -l or -r, both options to set local and remote loopback at the same time (if supported by the driver), or none of them to turn off any loopback.

-l level

enable local loopback.

-r level

enable remote loopback.

-q level

query loopback levels supported by the interface.

-V

print version number of atmloop on standard output and exit.

## AUTHOR
Werner Almesberger, EPFL ICA <Werner.Almesberger@epfl.ch>

## SEE ALSO
atmdiag(8), sonetdiag(8)


atmsigd

title: atmsigd(8)

summary: ATM signaling demon

text:
# atmsigd(8)

## NAME
atmsigd - ATM signaling demon

## SYNOPSIS
atmsigd [-b] [-c config_file] [-d] [-D dump_dir] [-l logfile] [-m mode] [-n] [-q qos] [-t trace_length] [-u uni_version] [[itf.]vpi.vci [input output]]

atmsigd -V

## DESCRIPTION
atmsigd implements the ATM UNI signaling protocol. Requests to establish, accept, or close ATM SVCs are sent from the kernel (using a comparably simple protocol) to the signaling demon, which then performs the dialog with the network.

Note that atmsigd is not able to accept or establish connections until the local ATM address of the interface is configured by ilmid or manually using atmaddr.

The default signaling VC (interface 0, VPI 0, VCI 5) can be overridden on the command line by specifying a different PVC address.

When overriding the default VC, optionally a pair of named pipes to use for communicating with the user of signaling can be specified. Normally, the kernel is the user of signaling and atmsigd opens a special socket for communication with it.

If atmsigd is killed, all system calls requiring interaction with it will return with an error and set errno to EUNATCH.

## OPTIONS
-b

Run in background (i.e. in a forked child process) after initializing.

-c config_file

Use the specified configuration file instead of /etc/atmsigd.conf If an option is specified in the configuration file and on the command line, the command line has priority.

-d

Enables (lots of) debugging output. By default, atmsigd is comparably quiet.

-D dump_dir

Specifies the directory to which atmsigd will write status and trace dumps. If -D is not specified, dumps are written to /var/tmp.

-l logfile

Write diagnostic messages to the specified file. The special name syslog is used to send diagnostics to the system logger, stderr is used to send diagnostics to standard error. If -l is absent, the setting in atmsigd.conf is used. If atmsigd doesn't specify a destination either, messages are written to standard error.

-m mode

Set the mode of operation. The following modes are available: user for the user side (the default), network for the network side (useful if you have two PCs but no switch), and switch for operation with a signaling relay in a switch.

-n

Prints addresses in numeric format only, i.e. no address to name translation is attempted.

-q qos

Configures the signaling VC to use the specified quality of service (see qos(7) for the syntax). By default, UBR at link speed is used on the signaling VC.

-t trace_length

Sets the number of entries that should be kept in the trace buffer. -t 0 disables tracing. If -t is not specified, atmsigd uses a default of 20 trace entries.

-u uni_version

Sets the signaling mode. The following modes are supported: uni30 for UNI 3.0, uni31 for UNI 3.1, uni31+uni30 for UNI 3.1 with 3.0 compatibility, uni40 for UNI 4.0, and uni40+q.2963.1 for UNI 4.0 with Q.2963.1 peak cell rate renegotiation.

-V

Prints the version number of atmsigd on standard output and exits.

## FILES
/etc/atmsigd.conf

default configuration file

/var/tmp/atmsigd.pid.status.version

default location of status dumps

/var/tmp/atmsigd.pid.trace.version

default location of signaling trace dumps

## DEBUGGING
When receiving a SIGUSR1 signal, atmsigd dumps the list of all internal socket descriptors. With SIGUSR2, it dumps the contents of the trace buffer. If a dump directory was set, dumps are written to files called atmsigd.pid.status.number and atmsigd.pid.trace.number, respectively, with number starting at zero and being incremented for every dump. If no dump directory is set, dumps are written to standard error.

Dumps are also generated whenever atmsigd detects a fatal error and terminates. No attempt is made to catch signals like SIGSEGV.

## BUGS
The generation of traces is a comparably slow process which may already take several seconds for only 100 trace entries. To generate a trace dump, atmsigd therefore forks a child process that runs in parallel to the signaling demon.

## AUTHOR
Werner Almesberger, EPFL ICA <Werner.Almesberger@epfl.ch>

## SEE ALSO
atmaddr(8), atmsigd.conf(4), ilmid(8), qos(7)


atmtcp

title: atmtcp(8)

summary: set up ATM over TCP connections

text:
# atmtcp(8)

## NAME
atmtcp - set up ATM over TCP connections

## SYNOPSIS
atmtcp [-d] [-v] command ...

atmtcp -V

## DESCRIPTION
The main purpose of atmtcp is to establish TCP connections and to configure them as virtual ATM devices. Such pairs of "ATM over TCP" devices are connected as if they were real ATM adapters linked by a cable or fiber, i.e. SDUs sent on a given VPI/VCI are received at the other end on the same VPI/VCI.

Virtual interfaces and ATM over TCP connections are called links. Other link types supported by atmtcp are real interfaces, files for recording and playback of ATM traffic, and printing a hex dump of the PDU content on standard output. Any pair of such links can be connected with atmtcp. If additional links are attached to such a connection, they send to all other links, except to the first link and the respective sender, and they receive from all other links.

atmtcp can operate with two types of virtual interfaces: ephemeral or persistent. By default, atmtcp interfaces are ephemeral. When the atmtcp process that created an interface terminates, the virtual ATM device is removed as soon all VCs are closed. However, if the interface was previously created as a persistent interface, only the communication stops, but the interface and all VCs on it remain intact. Attempts to send data on an atmtcp interface in this state fail silently, i.e. the interface behaves just like a real ATM interface without a wire. A new atmtcp process can then attach to the interface and resume operation. Persistent interfaces need to be removed explicitly.

If atmtcp has any readable links after processing the command line, it enters a loop to perform the data forwarding. If no readable links have been specified, atmtcp terminates after processing the command line. If any setup operation fails, atmtcp terminates at this point and does not attempt to cancel previous operations (e.g. creation of permanent interfaces).

## OPTIONS
-d

print detailed progress information on standard error.

-v

print some progress information on standard error.

-V

print version number of atmtcp on standard output and exit.

## COMMANDS
create [itf]

create a persistent interface. If no interface number is specified, atmtcp uses the default value 0.

remove [itf]

remove a persistent interface. If the interface is still in use, it is marked as ephemeral and will be removed as soon as all VCs are closed. If no interface number is specified, atmtcp uses the default value 0.

virtual [itf]

link to the corresponding virtual (ATM over TCP) interface. If no interface number is specified, the kernel assigns the first available number.

real [itf]

link to the corresponding ATM interface. If no interface number is specified, atmtcp uses the default value 0. If a link requests that a VC be opened, atmtcp will attempt to open a VC with the specified QoS parameters on that interface. If the operation succeeds, data can be sent or received on that VC. If the operation fails, an error code is returned to the requester. Note that only data arriving on open VCs can be received and that a real ATM interface never initiates a connection. atmtcp can share ATM interfaces with other applications.

connect host [port]

connect to an instance of atmtcp running on the specified host. If the port argument is omitted, atmtcp uses the default port 2812.

switch host line [port]

like connect, but connects to an ATM over TCP "switch" and selects the specified virtual line.

listen [port]

listen for an incoming ATM over TCP connection. If the port argument is omitted, atmtcp uses the default port 2812. atmtcp waits until the connection is established. Only one connection is accepted per listen command.

listen-bg [port]

like listen, but run in background after beginning to listen.

read file [stream]

play back all streams from the specified file. If a stream number is specified, only that stream is played back.

write file

record the traffic of all links in the specified file. The PDUs from each link are stored in a stream with the same number as the link.

print

print a hex dump of the content of all received PDUs on standard output.

bg

continue to run in background (i.e. in a forked child process).

wait [seconds]

wait for the specified number of seconds. If no time is specified, atmtcp waits for a newline on standard input.

## RESTRICTIONS
Due to recent protocol changes, atmtcp is currently not compatible with the ATM over TCP "switch".

Only AAL SDUs are exchanged, no segmentation or reassembly is performed. That implies that using different AALs (e.g. AAL5 and AAL0) on either side will reveal limitations of this emulation.

The atmtcp process needs to run during the the whole lifetime of the connection.

## EXAMPLES
Create a pair of virtual ATM over TCP interfaces on the local host and connect them:

```
  # session A

  atmtcp virtual listen

  # session B

  atmtcp virtual connect localhost
```

Create virtual interface 1, connect it to real ATM interface 0, then start atmsigd on the virtual interface, and log all the traffic in a file:

```
  atmtcp virtual 1 real 0 write /tmp/log

  atmsigd 1.0.5
```

Take the previously created file and examine the traffic sent from atmsigd using saaldump:

```
  # session A

  atmtcp virtual 1 read /tmp/log 0 wait

  # session B

  saaldump 1.0.5

  # press [Enter] in session A
```

## AUTHOR
Werner Almesberger, EPFL ICA <Werner.Almesberger@epfl.ch>

## SEE ALSO
atmdiag(8)


title: br2684ctl(8)

summary: RFC1483/2684 Bridge Daemon

text:
# br2684ctl(8)

## NAME
br2684ctl - RFC1483/2684 Bridge Daemon

## SYNOPSIS
br2684ctl [ -b ] [[ -c n ] [ -e 0|1 ] [ -p 0|1 ] [ -s sndbuf ] [ -a [itf].vpi.vci ]] ...

## PARAMETERS
-a [itf].vpi.vci

ATM PVC number, VPI and VCI. (Required)

-b

Puts the process in the background.

-c n

br2684 interface number such as 0, 1, ... (Required)

-e 0|1

Encapsulation method: 0=LLC, 1=VC mux (the default is 0 or LLC)

-p 0|1

Payload method: 0=Routed, 1=Bridged (the default is 1 or Bridged)

-s sndbuf

Send buffer size. Default is 8192.

## DESCRIPTION
br2684ctl handles RFC1483/2684 bridged PDUs. This is most often used in ADSL scenarios where usually the subscribers' ethernet traffic is encapsulated in ATM AAL5 (by bridging ADSL modems) according to RFC2684. The subscriber-side ADSL modem can be external with an ethernet connector or an internal ADSL card in a PC. RFC1483 has been obsoleted by RFC2684.

For example it is possible to set up your Linux box to handle several ATM PVC's with bridged-1483 (sometimes referred as SNAP) encapsulation. The Linux network stack might provide DHCP, IP masquerading, IP firewall services or bridge the Ethernet frames just like it had several ethernet interfaces. In fact it can have several (logical) ethernet interfaces, where ATM is just used as a carrier.

## USAGE
br2684ctl creates a new network interface named nas[n] which is bound to an specific ATM PVC. It requires two mandatory arguments: -c, the interface number, and -a, the ATM PVC. It should be noted that the order of the command arguments matter; -c should be followed by -a. You can create as many interfaces as necessary in one go, just make a long command line ;)

For example, following command will create a nas0 interface which uses the ATM PVC with VPI=0 and VCI=401. You need to configure the PVC connection 0.401 on the ATM switch manually.

% br2684ctl -c 0 -a 0.401

The command will only create a new interface nas0. Next step is to assign an IP address and netmask to the interface nas0 using the ifconfig command. Using ifconfig, you can also assign a Ethernet MAC address to the interface nas0, if necessary.

% ifconfig nas0 192.168.2.1 netmask 255.255.255.0

Messages are logged to the LOCAL2 syslog facility.

## FILES
/var/run/br2684ctl-<iface>.pid

## NOTES
This man page is based on a tutorial by by Joonbum Byun <jbyun@megaxess.com>

## SEE ALSO
qos(7)


esi

title: esi(8)

text:
# esi(8)

## NAME
esi - get or set the end system identifier (ESI)

## SYNOPSIS
esi [itf]

esi [-f] esi [itf]

esi -V

## DESCRIPTION
esi is used to show or set the end system identifier (ESI, a unique six-byte number corresponding to the MAC address of LAN technologies like Ethernet) of an ATM interface. If the interface number itf is omitted, interface 0 is used by default. The esi argument is a string of twelve hex digits.

Only the ESI stored in the kernel is accessed; esi does not change the ESI stored on the NIC. If a non-zero ESI is already set on an interface, the -f option has to be used to overwrite it.

Note that ESI changes are not automatically propagated throughout the system, e.g. to ilmid. esi should therefore be used early during system initialization.

## OPTIONS
-f

force overwriting an existing ESI.

-V

print version number of esi on standard output and exit.

## AUTHOR
Werner Almesberger, EPFL ICA <Werner.Almesberger@epfl.ch>

## SEE ALSO
ilmid(8)


ilmid

title: ilmid(8)

text:
# ilmid(8)

## NAME
ilmid - Integrated Local Management Interface Daemon

## SYNOPSIS
ilmid [ -b ] [ -d ] [ -v ] [ -l logfile ] [ -x ] [ -q qos ] [ -i local_ip ] [ -u uni ] <interface>

## PARAMETERS
-b

Puts the process in the background.

-d

Turn on debugging output.

-v

Verbose.

-l logfile

Set the location of the log file.

-x

No var bindings?

-q qos

Set the qos parameters to use on the ilmi VC.

-i local_ip

the address that should be used by the switch for network management.

-u uni

uni version. This can be 3.0, 3.1 or 4.0.

## DESCRIPTION
ilmid implements SNMP on an ATM PVC. It is used to negotiate operating parameters with a switch.

## SEE ALSO
atmsigd(8)


lecs

title: lecs(8)

summary: ATM LAN Emulation service demons

text:
# lecs(8)

## NAME
les, bus - ATM LAN Emulation service demons

## SYNOPSIS
lecs [-l listen_address] [-f configuration_file] [-d ]

## DESCRIPTION
LE Service consists of three components: LAN Emulation Configuration Server (lecs), LAN Emulation Server ( les(8)) and Broadcast and Unknown Server (bus(8)).

Lecs implements the distribution of LECs to different emulated LANs. This is done by giving different LAN Emulation Server ATM addresses to LECs. Distribution is based on lecs's configuration database and information provided by the LE client. It is not required that a lecs exists for all emulated LANs. It is possible to bypass this configuration phase by directly telling ATM address of the les(8) to the LEC.

Configuration file example for lecs:

```
# Our ATM address (should be included to differentiate us from
# e.g. LEC)
# Must be before ELAN definitions
470023000000030300010002010020ea000ae905
# ELAN name is inside brackets.
# Parameters below are for Ethernet type LE (Linux & almost all
# other LE clients)
[tut-lane1]
# Address of the LES
LES:=470023000000030300010002010020ea000ae901
# 802_3 or 802_5 (802_3 = Ethernet)
Type:=802_3
# 1515, 4544, 9234 or 18190 (1516= Ethernet)
Max_Frame:=1516
# ATM address for hosts that are guided to this ELAN.
# Wildcard is x or X.
470023000000030300010002010020ea0005aax0
470023000000030000010002010020ea0005bx00
47.002300000003030001000201.00603E2FDX23.00
470023000000030300010002010020ea000Xxx00
DEFAULT
# Another ELAN, which has empty name
[asdf]
# This directive sets this elan as the default i.e. it will be
# included if LEC's configure request could not be matched to
# other ELANs
#DEFAULT
LES= 470023000000030300010002010020ea000ae902
Type=Ethernet
```

Rules for finding ELAN definitions using information provided in LE_CONFIGURE_REQUEST and the configuration file are as follows:

```
1. Find an entry where ELAN-NAME matches exactly and an

   ATM address of the LEC is found in ELAN definition.

   These are to match exactly with the information given in

   LE_CONFIGURE_REQUEST. If ELAN-NAME is found, but ATM

   address doesn't match then reject with reason "Permission

   denied".
2. Search for first ELAN which matches in type of emulated LAN,

   maximum frame size and ATM address of the LEC.
3. If matching ELAN was not found, return default ELAN

   definitions.
4. No match, so request is rejected with reason "No

   Configuration".
```

```

```

SIGHUP restarts the server.

## OPTIONS
-d

Reads the configuration file, dumps its contents and exits.

-l listen_address

Use the listen_address to where wait connections.

-f configuration_file

Use the specified configuration file instead of .lecs_conf.

## FILES
.lecs_conf

configuration file

## BUGS
Undocumented.

## AUTHOR
Marko Kiiskila, TUT <carnil@cs.tut.fi>

## SEE ALSO
les(8), atmsigd(8), zeppelin(8)


les

title: les(8)

summary: ATM LAN Emulation service demons

text:
# les(8)

## NAME
les, bus - ATM LAN Emulation service demons

## SYNOPSIS
les [-d module] [-m module] [-f configuration_file]

bus [-d module] [-m module] [-f configuration_file]

## DESCRIPTION
LE Service consists of three components: LAN Emulation Configuration Server (lecs(8)), LAN Emulation Server (les) and Broadcast and Unknown Server (bus).

Les performs the control coordination function for the emulated LAN. LE clients register MAC addresses and/or route descriptors they represent to les, and later query it when they want to resolve MAC addresses/route descriptors into ATM addresses. Other LE control messages which are to be distributed to every client in ELAN are also sent to les. Les forwards these messages using Control Distribute VCC which it has set up to every client in ELAN.

Bus handles data sent by clients to broadcast and multicast MAC addresses and some of the data directed to unicast addresses. LE Client has a possibility to send data directed to some unicast address to the bus before target's ATM address has been resolved and the Data Direct VCC has been established.

Configuration file example for les and bus:

```
[main]
memdebug=True
debug=True
[load]
#memdebug=True
#debug=True
[conn]
debug=True
#S1, LE Server's ATM address
#S1=:47:00:23:00:00:00:03:00:00:01:00:02:01:00:20:ea:00:05:aa:00
S1=:47:00:23:00:00:00:03:03:00:01:00:02:01:00:20:ea:00:0a:e9:01
#S2, LAN Type
S2="802.3"
#S3, Maximum Frame Size
S3=1516
#S4, Join Timeout, s
S4=15
#S5, Maximum Frame Age, s
S5=6
#S6, BUS Atm address
S6=:47:00:23:00:00:00:03:03:00:01:00:02:01:00:20:ea:00:0a:e9:02 #viulu
#S6=0,0,170
#ELANNAME="asdf"
```

The configuration file contains each modules name in brackets followed by variable definitions for that module. The definitions are of form variable=value, where value can be either an integer, a truth value (True/False), a string enclosed in double quotes ("string") or an ATM address in hexadecimal format. Variables that can be set are the debug/memdebug for each module and variables S1-S6 as defined in LE specification.

```
S1=Address of the LES. This address is used in ATM

   signalling.
S2=Type of the emulated LAN. Valid values is "802.3".
S3=Maximum frame size. Valid value is 1516.
S4=Join Timeout. Time in seconds which LES waits for

   LE_JOIN_REQUEST before tearing down a connection.
S5=Maximum frame Age. Currently not used.
S6=Address of the BUS. This address is used in ATM signalling.
ELANNAME= Name of the emulated LAN
```

SIGHUP causes restart of the server. All resources are released and server is started. SIGUSR1 causes the server to dump its internal state. SIGUSR2 shuts down the server (hopefully) gracefully.

## OPTIONS
-d module

Set debugging messages on for a module. "All" sets debugging on for all modules.

-m module

Set memory debugging messages on for a module. "All" sets debugging on for all modules.

-f configuration_file

Use the specified configuration file instead of .lanevars.

## FILES
.lanevars

configuration file

## BUGS
Servers don't establish point-to-multipoint connections to LE clients as the specification states, which means that some LE clients won't work with these servers.

Supports only IEEE 802.3 / Ethernet type of ELANs.

This manual page is confusing.

## AUTHOR
Marko Kiiskila, TUT <carnil@cs.tut.fi>

## SEE ALSO
lecs(8), atmsigd(8), zeppelin(8)


mpcd

title: mpcd(8)

summary: ATM MPOA (Multi\-Protocol Over ATM) client daemon

text:
# mpcd(8)

## NAME
mpcd - ATM MPOA (Multi-Protocol Over ATM) client daemon

## SYNOPSIS
mpcd [ -s Control ATM address ] [ -l Data ATM address ] [ -c MPS control ATM address ] [ -i Interface number ] [ -m MPS MAC address ] [ -L LEC address [ -n ELAN name ] [ -C LECS Address ]]

## DESCRIPTION
MPOA client internetwork layer shortcuts. Using these shortcuts MPCs forward unicast internetwork layer packets effectively over ATM without need for routing protocols.

MPC has two roles; ingress and egress. In ingress role MPC detects flows destined outside it's own subnet and tries to establish shortcuts to those destinations. In egress role MPC accepts shortcuts and packets arriving on those shortcuts. Maintaining shortcuts is done with the help of MPOA server

Just as the Linux LAN Emulation client, MPOA client is also divided in two parts. The parts are kernel component and a daemon process. The daemon opens and receives data shortcuts and control connections with the kernel component. The kernel component tallies packets flowing out from the LANE device and makes the decision if a packet should be forwarded using LANE or MPOA shortcuts.

If the daemon is killed with SIGHUP it will close all the open connections, purge ingress and egress cache entries, query LECS if applicable and then restart itself.

Linux MPOA client only supports non-LLC-muxed shortcuts. The number of supported MPOA clients is unlimited.

## OPTIONS
-s Control ATM address

Local ATM address this MPC uses for MPOA control connections.

-l Data ATM address

Local ATM address from and to which MPOA shortcuts are established.

-c MPS control ATM address

ATM address of MPS. Only needed if MPS can not advertise it by itself.

-i Interface number

The interface number of LEC this MPC serves. E.g. 2 for "lec2".

-m MPS MAC address

MAC address of default router where MPS recides. Only useful if the MPOA server fails to advertise itself.

-L LEC address

Listen address of the LANE client zeppelin. mpcd uses this address as its own ATM address when it queries LECS for MPC configuration parameters. If this option is not present then mpcd will not use LECS to query for configuration parameters. This option is normally the same as zeppelin's -l option.

-n ELAN name

Name of the ELAN for which mpcd asks for parameters when it connects to LECS. If this option is not given, LECS should respond with parameters belonging to the default ELAN if one exists. This option is normally the same as zeppelin's -n option.

-C LECS address

ATM address of LECS mpcd asks for parameters. If this option is left empty and -L is given, mpcd uses ATM Forum assigned Well-Known LECS address. This option is normally the same as zeppelin's -c option.

## EXAMPLES
This script snippet shows how to run LANE and MPOA. After UNI signalling and ILMI have been started LANE (zeppelin) and MPOA (mpcd) are started. The commented out line shows how to start mpcd so that it queries LECS for MPC parameters.

Arguments jaarli[1-3] are local ATM addresses listed in file /etc/hosts.atm.

ATM=/usr/src/atm

case "$1" in

start)

cd $ATM

if [ -x sigd/atmsigd ] ; then

sigd/atmsigd -b

fi

if [ -x ilmid/ilmid ] ; then

ilmid/ilmid -b -x

fi

if [ -x led/zeppelin ] ; then

led/zeppelin -2 -n sampo -i2 -l jaarli3 &

ifconfig lec2 10.10.10.208 \

netmask 255.255.255.192 \

broadcast 10.10.10.255

ifconfig lec2 up

route add default gw 10.10.10.193

fi

if [ -x mpoad/mpcd ] ; then

mpoad/mpcd -i2 -s jaarli1 -l jaarli2 &

\#mpoad/mpcd -i2 -s jaarli1 -l jaarli2 \

-L jaarli3 -n sampo &

fi

;;

esac

exit 0

## BUGS
Supports only Ethernet type of ELANs. Probably others too.

## AUTHORS
Heikki Vatiainen <hessu@cs.tut.fi>, Sampo Saaristo <s156953@cs.tut.fi>

## SEE ALSO
zeppelin(8), atmsigd(8)


zeppelin

title: zeppelin(8)

text:
# zeppelin(8)

## NAME
zeppelin - ATM LAN Emulation client demon (LED) Zeppelin

## SYNOPSIS
zeppelin [-b ] [-c LECS_address | -s LES_address] [-e esi] [-n VLAN_name] [-m mesg_mask] [-l listen_address | selector] [-i interface_number] [-I physical_interface_number] [-t 1516|1580|4544|9234|18190] [-1 ] [-2 ] [-p ] [-F logfile] [-f Fore_specific_name]

## DESCRIPTION
A LAN Emulation Client is an entity in an ATM endstation that performs data forwarding, address resolution and other control functions. It uses the LUNI interface when communicating with other components in emulated LANs. It provides upper protocol layers a MAC like interface similar to IEEE 802.3/Ethernet or IEEE 802.5/Token Ring LAN.

LAN Emulation client code is divided into two parts: user space application LAN Emulation Demon called (LED) zeppelin(8), and the kernel component. Zeppelin is responsible for control operations needed in LAN Emulation clienthood. It forms the necessary VCCs and receives all the LE control frames and acts accordingly. It also controls the operation of the LEC kernel component.

Linux LEC supports only Ethernet type of emulated LAN.

SIGHUP causes restart of the LEC. All resources are released and zeppelin is started.

## OPTIONS
-b

Run in background (i.e. in a forked child process) after initializing kernel interface.

-c LECS_address

ATM address of lecs(8) (Lan Emulation Configuration Server), if not set, Well-Known server address is used.

-s LES_address

ATM address of les(8) (Lan Emulation Server), can be used in bypassing configuration phase in joining emulated Lan i.e lecs address is not used.

-e esi

Mac address to use when communicating in Emulated LAN. E.g. 00:20:22:23:04:05 .

-n VLAN_name

Name of the virtual LAN to which joining is requested. This is used in LE_CONFIGURE_REQUEST to LECS or LE_JOIN_RESPONSE to LES, if configuration phase is bypassed.

-m mesg_mask

Sometimes one wants to know more what is happening in LE daemon e.g. when nothing works. This is a hexadecimal long value setting global message mask. 0 = No messages, ffff = All messages.

-l listen_address | selector

Local ATM address that zeppelin uses as local binding point in signalling. Use this if you are running more than one client or a set of LE servers. The local ATM address can be specified by either giving the full ATM address or the desired selector byte.

-i interface_number

Linux LEC supports up to 40+8 network interfaces. The interface_number tells zeppelin to which of these to attach. Ethernet type network interfaces are numbered from "lec0" to "lec39" and Token Ring interfaces are from "lec40" to "lec47". These parameters are tweakable during the kernel compile, see <linux/atmlec.h>.

-I physical_interface_number

The physical interface this LANE client should bind to. If your host has multiple ATM network cards, you can use this option to choose which card this zeppelin will use.

-t MTU

The MTU of ELAN to join. You need to also use ifconfig(8) to set the MTU of the LANE interface.

-1

Run as LANEv1 client. This is the default.

-2

Run as LANEv2 client. This is required by MPOA.

-p

Enable proxy. When started with this option, it is possible to bridge packets between ATM and Ethernet. That is, you can use LANE interfaces with normal bridging. See the Bridging mini-Howto for more info.

-F logfile

Instead of writing debug messages to stderr, write the messages to the file logfile. Use syslog as the file name to use the syslog(3) facility.

-f Fore specific name

The LANE servers on Fore ATM switches can display a special name if a client can supply one. This name shows with command ´conf lane les show advanced´.

## TOKEN RING CONSIDERATIONS
A number of lec interfaces is reserved for Token Ring ELANs when the kernel is compiled with Token Ring (CONFIG_TR) support. See the discussion about interface_number command line option above. The Linux Token Ring LANE client does not support bridging between legacy Token Ring and ATM parts of the ELAN, so using the -p option is not recommended. Token Ring support has received less testing than its Ethernet counterpart.

## FILES
/var/run/lec[interface

The file containing the process id of zeppelin.

## BUGS
John Bonham died 1980 and Led Zeppelin broke.

Please report any other bugs to Heikki Vatiainen <hessu@cs.tut.fi>

## AUTHORS
Marko Kiiskila, TUT <carnil@cs.tut.fi> and Heikki Vatiainen, TUT <hessu@cs.tut.fi>

## SEE ALSO
lecs(8), mpcd(8), atmsigd(8), les(8), qos(7)


cyclicdeadline

package: linux-rt-tests

title: cyclicdeadline(8)

text:
# cyclicdeadline(8)

## NAME
cyclicdeadline - This program is used to test the deadline scheduler (SCHED_DEADLINE) using a cyclictest style program

## SYNOPSIS
cyclicdeadline [-a [CPUSET]] [-D TIME] [-h] [-i INTV] [--json FILENAME] [-s STEP] [-t NUM] [-q]

## DESCRIPTION
cyclicdeadline is a cyclictest style program for testing the deadline scheduler

## OPTIONS
-a --affinity [CPUSET]

Comma / hypen separated list of CPUs to run deadline tasks on

-D --duration TIME

Specify a length for the test to run Append 'm', 'h', or 'd' to specify minutes, hours, or days

-h --help

Show this help menu

-i --interval INTV

The shortest deadline for the tasks in us. (default 1000us)

--json=FILENAME

Write final results into FILENAME, JSON formatted.

-s --step STEP

The amount to increase the deadline for each task in us. (default 500us)

-t --threads NUM

The number of threads to run as deadline (default 1)

-q, --quiet

Print a summary only on exit. Useful for automated tests, where only the summary output needs to be captured.

## AUTHOR
cyclicdeadline was written by Steven Rostedt <rostedt@goodmis.org>

This manual page was written by John Kacur <jkacur@redhat.com>


cyclictest

title: cyclictest(8)

summary: High resolution test program

text:
# cyclictest(8)

## NAME
cyclictest - High resolution test program

## SYNOPSIS
cyclictest

[ -hfmnqrsvMS ] [-a proc ] [-A align ] [-b usec ] [-c clock ] [-d dist ] [-h histogram ] [-i intv ] [--json filename ] [-l loop ] [-o red ] [-p prio ] [-t num ] [-D time] [-w] [-W] [-y policy ] [ -S | -U ]

## OPTIONS
These programs follow the usual GNU command line syntax, with long options starting with two dashes ('--').

A summary of options is included below.

-a, --affinity[=PROC-SET]

Run threads on the set of processors given by PROC-SET. If PROC-SET is not specified, all processors will be used. Threads will be assigned to processors in the set in numeric order, in a round-robin fashion.

The set of processors can be specified as A,B,C, or A-C, or A-B,D-F, and so on*. The ! character can be used to negate a set. For example, !B-D means to use all available CPUs except B through D. The cpu numbers are the same as shown in the processor field in /proc/cpuinfo. See numa(3) for more information on specifying CPU sets. * Support for CPU sets requires libnuma version >= 2. For libnuma v1, PROC-SET, if specified, must be a single CPU number.

-A, --align=USEC

Align thread wakeups to a specific offset in microseconds

-b, --breaktrace=USEC

Send break trace command when latency > USEC

-c, --clock=CLOCK

select clock

0 = CLOCK_MONOTONIC (default)

1 = CLOCK_REALTIME

-d, --distance=DIST

Distance of thread intervals in us, default = 500

-D, --duration=TIME

Specify a length for the test run.

Append 'm', 'h', or 'd' to specify minutes, hours or days.

--latency=PM_Q0S

write PM_Q0S to /dev/cpu_dma_latency

-F, --fifo=<path>

Create a named pipe at path and write stats to it

-h, --histogram=US

Dump latency histogram to stdout after the run. US is the max latency time to be be tracked in microseconds. This option runs all threads at the same priority.

-H, --histofall=MAXLATENCYINUS

Same as -h except that an additional histogram column is displayed at the right that contains summary data of all thread histograms. If cyclictest runs a single thread only, the -H option is equivalent to -h.

--histfile=<path>

Dump the latency histogram to <path> instead of stdout.

-i, --interval=INTV

Set the base interval of the thread(s) in microseconds (default is 1000us). This sets the interval of the first thread. See also -d.

--json=FILENAME

Write final results into FILENAME, JSON formatted.

-l, --loops=LOOPS

Set the number of loops. The default is 0 (endless). This option is useful for automated tests with a given number of test cycles. Cyclictest is stopped once the number of timer intervals has been reached.

--laptop

Save battery when running cyclictest. This will give you poorer realtime results, but will not drain your battery so quickly.

--mainaffinity=CPUSET

Run the main thread on CPU #N. This only affects the main thread and not the measurement threads

-m, --mlockall

Lock current and future memory allocations to prevent being paged out

-M, --refresh_on_max

Delay updating the screen until a new max latency is hit. (useful for running cyclictest on low-bandwidth connections)

-N, --nsecs

Show results in nanoseconds instead of microseconds, which is the default unit.

-o, --oscope=RED

Oscilloscope mode, reduce verbose output by RED.

-p, --prio=PRIO

Set the priority of the first thread. The given priority is set to the first test thread. Each further thread gets a lower priority: Priority(Thread N) = max(Priority(Thread N-1) - 1, 0)

--policy=NAME

set the scheduler policy of the measurement threads where NAME is one of: other, normal, batch, idle, fifo, rr

--priospread

spread priority levels starting at a specified value

-q, --quiet

Print a summary only on exit. Useful for automated tests, where only the summary output needs to be captured.

-r, --relative

Use relative timers instead of absolute. The default behaviour of the tests is to use absolute timers. This option is there for completeness and should not be used for reproducible tests.

-R, --resolution

Check clock resolution, calling clock_gettime() many times. List of lock_gettime() values will be reported with -X

--secaligned [USEC]

align thread wakeups to the next full second and apply the optional offset.

-s, --system

Use sys_nanosleep and sys_setitimer instead of posix timers. Note, that -s can only be used with one thread because itimers are per process and not per thread. -s in combination with -n uses the nanosleep syscall and is not restricted to one thread.

-S, --smp

Set options for standard testing on SMP systems. Equivalent to using the options: "-t -a" as well keeping any specified priority equal across all threads

--spike=<trigger>

record all spikes > trigger

--spike-nodes=[num of nodes]

These are the maximum number of spikes we can record.

The default is 1024 if not specified.

--smi

Enable SMI count/detection on processors with SMI count support.

-t, --threads[=NUM]

Set the number of test threads (default is 1). Create NUM test threads. If NUM is not specified, NUM is set to the number of available CPUs. See -d, -i and -p for further information.

--tracemark

write a trace mark when -b latency is exceeded.

-u, --unbuffered

force unbuffered output for live processing

-v, --verbose

Output values on stdout for statistics. This option is used to gather statistical information about the latency distribution. The output is sent to stdout. The output format is: n:c:v

where n=task number c=count v=latency value in us.

--dbg_cyclictest

Print info userful for debugging cyclictest

-x, --posix_timers

Use POSIX timers instead of clock_nanosleep.

## SEE ALSO
numa(3), numactl(8),

## AUTHOR
cyclictest was written by Thomas Gleixner <tglx@linuxtronix.de>.

This manual page was written by Alessio Igor Bogani <abogani@texware.it>, for the Debian project (but may be used by others).

Updated by John Kacur <jkacur@redhat.com>


title: deadline_test(8)

summary: High resolution test program

text:
# deadline_test(8)

## NAME
deadline_test - High resolution test program

## DESCRIPTION
This program is used to test the deadline scheduler (SCHED_DEADLINE tasks)

## SYNOPSIS
deadline_test [ -hb ] [ -c CPUSET ] [ -i INTV ] [ -p PERCENT ] [ -P PERCENT ] [ -r PRIO ] [ -s STEP ] [ -t NUM ]

## OPTIONS
-b

Bind on the last cpu. (shortcut for -c <lastcpu>)

-c CPUSET

Comma/hyphen separated list of CPUs to run deadline tasks on

-h

Show this help menu

-i INTV

The shortest deadline for the tasks

-p PERCENT

The percent of bandwidth to use (1-90%)

-P PERCENT

The percent of runtime for execution completion (default 100%)

-r PRIO

Add an RT task with given prio to stress system

-s STEP

The amount to increase the deadline for each task in us (default 500us)

-t NUM

The number of threads to run as deadline (default 1)

## AUTHOR
Deadline test was written by Steven Rostedt <rostedt@goodmis.org>

This manual page was written by John Kacur <jkacur@redhat.com>


title: determine_maximum_mpps(8)

text:
# determine_maximum_mpps(8)

## NAME
determine_maximum_mpps - Determine the maximum mpps the machine can handle

## SYNOPSIS
determine_maximum_mpps [-a cpulist] [-m maxlat] [-n cycles] [-f | -r] [-p priority] [-h]

## DESCRIPTION
determine_maximum_mpps will find the maximum mpps parameter which can sustain

1. 10 consecutive 30 second runs.

2. 1 run of 10 minutes.

Without violating the latency specified with $MAXLAT (default 20000)

## TERMINOLOGY
mpps : million-packets-per-second

## OPTIONS
-a cpulist

List of processors to run on. The default is processor 0

Numbers are separated by commas and may include ranges. Eg. 0,3,7-11

-m maxlat

Maximum latency in nanoseconds. The default is 20000. If the maximum is exceeded, that run of queuelat quits.

-n cycles

Extimated number of cycles it takes to process one packet. The default is 300

-f

Set the scheduling policy to SCHED_FIFO. This is the default if not specified.

-r

Set the scheduling policy to SCHED_RR.

-p priority

default priority = 1. Valid numbers are from 1 to 99

-h

help

## AUTHOR
determine_maximum_mpps was written by

Marcelo Tosatti <mtosatti@redhat.com>

This man page was written by John Kacur <jkacur@redhat.com>


title: get_cyclictest_snapshot(8)

text:
# get_cyclictest_snapshot(8)

## NAME
get_cyclictest_snapshot - Get a snapshot of running instances of cyclictest

## SYNOPSIS
get_cyclictest_snapshot

[[-h] [-l] [-s [pid [pid]

[[-p [pid [pid ...]]]]

## OPTIONS
Without options, this program will send USR2 to cyclictest to create a snapshot and then print it out.

Optional arguments:

-h, --help

show this help message and exit

-l, --list

list the main pid(s) of running instances of cyclictest

-s [pid [pid ...]], --snapshot [pid [pid ...]]

take a snapshot of running instances of cyclictest

by sending USR2 to cyclictest

-p [pid [pid ...]], --print [pid [pid ...]]

print the snapshots

## SEE ALSO
cyclictest(8),

## AUTHOR
get_cyclictest_snapshot was written by John Kacur <jkacur at redhat dot com>


hackbench

title: hackbench(8)

summary: scheduler benchmark/stress test

text:
# hackbench(8)

## NAME
hackbench - scheduler benchmark/stress test

## SYNOPSIS
hackbench [-f|--fds NUM] [-F|--fifo] [-g|--groups NUM] [-h|--help] [-l|--loops LOOPS] [-p|--pipe] [-s|--datasize SIZE] [-T|--threads] [-P|--process]

## DESCRIPTION
Hackbench is both a benchmark and a stress test for the Linux kernel scheduler. It's main job is to create a specified number of pairs of schedulable entities (either threads or traditional processes) which communicate via either sockets or pipes and time how long it takes for each pair to send data back and forth.

## OPTIONS
These programs follow the usual GNU command line syntax, with long options starting with two dashes ("--").

A summary of options is included below.

-f, --fds=NUM

Defines how many file descriptors each child should use. Note that the effective number will be twice the amount you set here, as the sender and receiver children will each open the given amount of file descriptors.

-F,--fifo

Change the main thread to SCHED_FIFO after creating workers. This allows the management thread to run after many workers are created.

-g, --groups=NUM

Defines how many groups of senders and receivers should be started

-h, --help

-l, --loops=LOOPS

How many messages each sender/receiver pair should send

-p, --pipe

Sends the data via a pipe instead of the socket (default)

-s, --datasize=SIZE

Sets the amount of data to send in each message

-T, --threads

Each sender/receiver child will be a POSIX thread of the parent.

-P, --process

Hackbench will use fork() on all children (default behaviour)

Shows a simple help screen

## EXAMPLES
Running hackbench without any options will give default behaviour, using fork() and sending data between senders and receivers via sockets.

user@host: ~ $ hackbench

Running in process mode with 10 groups using 40 file descriptors each (== 400 tasks)

Each sender will pass 100 messages of 100 bytes

Time: 0.890

To use pipes between senders and receivers and using threads instead of fork(), run

user@host: ~ $ hackbench --pipe --threads (or hackbench -p -T)

Running in threaded mode with 10 groups using 40 file descriptors each (== 400 tasks)

Each sender will pass 100 messages of 100 bytes

Time: 0.497

Set the datasize to 512 bytes, do 200 messages per sender/receiver pairs and use 15 groups using 25 file descriptors per child, in process mode.

user@host: ~ $ hackbench -s 512 -l 200 -g 15 -f 25 -P

Running in process mode with 15 groups using 50 file descriptors each (== 750 tasks)

Each sender will pass 200 messages of 512 bytes

Time: 4.497

## AUTHORS
hackbench was written by Rusty Russell <rusty@rustcorp.com.au> with contributions from Yanmin Zhang <yanmin_zhang@linux.intel.com>, Ingo Molnar <mingo@elte.hu> and David Sommerseth <davids@redhat.com>

This manual page was written by Clark Williams <williams@redhat.com> and David Sommerseth <davids@redhat.com>

## HISTORY
This version of hackbench is based on the code downloaded from http://people.redhat.com/mingo/cfs-scheduler/tools/hackbench.c. Yanmin Zhang merged the original hackbench code from

http://devresources.linuxfoundation.org/craiger/hackbench/src/hackbench.c which uses fork() and a modified version from

http://www.bullopensource.org/posix/pi-futex/hackbench_pth.c which uses pthread only and gave the possibility to change behaviour at run time. Hackbench have since then gone through some more rewriting to improve error handling and proper tracking of fork()ed children, to avoid leaving zombies on the system if hackbench stops unexpectedly.


hwlatdetect

title: hwlatdetect(8)

text:
# hwlatdetect(8)

## NAME
hwlatdetect - program to control the ftrace kernel hardware latency detection

## SYNOPSIS
hwlatdetect [ --duration=<time> ] [--threshold=<usecs> ] [--window=<time interval> ] [--width=<time interval> ] [--hardlimit=<microsecond value> ] [--report=<path> ] [--debug ] [--quiet ] [--watch]

## DESCRIPTION
hwlatdetect is a program that controls the ftrace kernel hardware latency detector (hwlatdetector).hwlatdetector is used to detect large system latencies induced by the behavior of certain underlying hardware or firmware, independent of Linux itself. The code was developed originally to detect SMIs (System Management Interrupts) on x86 systems, however there is nothing x86 specific about it. It was originally written for use by the "RT" patch set since the Real Time kernel is highly latency sensitive.

SMIs are usually not serviced by the Linux kernel, which typically does not even know that they are occurring. SMIs are instead are set up by BIOS code and are serviced by BIOS code, usually for "critical" events such as management of thermal sensors and fans. Sometimes though, SMIs are used for other tasks and those tasks can spend an inordinate amount of time in the handler (sometimes measured in milliseconds). Obviously this is a problem if you are trying to keep event service latencies down in the microsecond range.

The ftrace hardware latency detector works by hogging all of the cpus for configurable amounts of time (by calling stop_machine()), polling the CPU Time Stamp Counter for some period, then looking for gaps in the TSC data. Any gap indicates a time when the polling was interrupted and since the machine is stopped and interrupts turned off the only thing that could do that would be an SMI.

The hwlatdetector script manages the mounting/unmounting of the debugfs as well as interacting with the ftrace hwlatdetector If the debugfs is already mounted then hwlatdetector will not unmount it after a run.

## OPTIONS
--duration=<time>{s,m,d}

Run the detector logic in for the specified duration. The duration is a base 10 integer number that defaults to a value in seconds. An optional suffix may be specified to indicate minutes, hours or days.

--threshold=<microsecond value>

Specify the TSC gap used to detect an SMI. Any gap value greater than <threshold> is considered to be the result of an SMI occurring.

--hardlimit=<microsecond value>

The test is considered to fail if a value above the hardlimit occurs. This affects the exit value of hwlatdetect

--window=<time value>{us,ms,s,m,d}

specify the size of the sample window. Converted to microseconds when passed to the kernel.

--width=<time value>{us,ms,s,m,d}

The amount of time within the sample window where the detector is actually sampling. Must be less than the --window value.

--report=FILENAME

Specify the output filename of the detector report. Default behavior is to print to standard output

--debug

Turn on debug prints

--quiet

Turn off all information prints

--watch

print sample data to stdout as it arrives

## AUTHOR
hwlatdetect was written by Clark Williams <williams@redhat.com>

hwlat_detector.ko was written by Jon Masters <jcm@redhat.com>


oslat

title: oslat(8)

summary: OS Latency Detector

text:
# oslat(8)

## NAME
oslat - OS Latency Detector

## SYNOPSIS
oslat

[ -shvz ] [ -b bucket-size ] [ -B bias ] [ -c cpu-list ] [ -C cpu-main-thread ] [ -f rt-prio ] [ --json filename ] [ -m workload-mem ] [-t runtime ] [ -T trace-threshold ] [ -w workload ]

## DESCRIPTION
oslat is an open source userspace polling mode stress program to detect OS level latency. The program runs a busy loop with no or various workloads, collecting TSC information and measuring the time frequently during the process.

## OPTIONS
-b, --bucket-size=N

Specify the number of the buckets (4-1024).

-B, --bias=USEC

Add a bias to all the buckets using the estimated mininum.

-c, --cpu-list=CPULIST

Specify CPUs to run on. For example, '1,3,5,7-15'.

-C, --cpu-main-thread=CORE

Specify which CPU the main thread runs on. Default is cpu0.

-f, --rtprio=PRIORITY

Using specific SCHED_FIFO priority (1-99). Otherwise use the default priority, normally it will be SCHED_OTHER.

--json=FILENAME

Write final results into FILENAME, JSON formatted.

-m, --workload-mem=SIZE

Size of the memory to use for the workload (e.g., 4K, 1M). Total memory usage will be this value multiplies 2*N, because there will be src/dst buffers for each thread, and N is the number of processors for testing.

-D, --duration=TIME

Specify test duration, e.g., 60, 20m, 2H (m/M: minutes, h/H: hours, d/D: days). By default the unit is s/second.

-T, --trace-threshold=THRESHOLD

Stop the test when threshold triggered (in USEC). At the meantime, print a marker in ftrace and stop ftrace too.

-w, --workload=WORKLOAD

Specify a kind of workload, default is no workload. Options: "no", "memmove".

-s, --single-preheat

Use a single thread when measuring latency at preheat stage NOTE: please make sure the CPU frequency on all testing cores are locked before using this parmater. If you don't know how to lock the freq then please don't use this parameter.

-h, --help

Show the help message.

-v, --version

Show the version of the program.

-z, --zero-omit

Don't display buckets in the output histogram if all zeros.

## AUTHOR
oslat was written by Peter Xu <peterx@redhat.com>.


title: pi_stress(8)

text:
# pi_stress(8)

## NAME
pi_stress - a stress test for POSIX Priority Inheritance mutexes

## SYNOPSIS
pi_stress [-d|--debug] [-D|--duration [-g|--groups N] [-i|--inversions INV] [--json FILENAME] [-m|--mlockall] [-p|--prompt] [-q|--quiet] [-r|--rr] [-s|--sched OPTS] [-u|--uniprocessor] [-v|--verbose] [-V|--version]

## DESCRIPTION
pi_stress is a program used to stress the priority-inheritance code paths for POSIX mutexes, in both the Linux kernel and the C library. It runs as a realtime-priority task and launches inversion machine thread groups. Each inversion group causes a priority inversion condition that will deadlock if priority inheritance doesn't work.

## OPTIONS
-d|--debug

Run in debug mode; lots of extra prints

-D TIME, --duration=TIME

Specify a length for the test run.

Append 'm', 'h', or 'd' to specify minutes, hours or days.

-g N|--groups=N

The number of inversion groups to run. Defaults to 10.

-h|--help

Display a short help message and options.

-i N|--inversions=N

N number of inversion conditions. This is the total number of inversions for all inversion groups. Default is -1 for infinite.

--json=FILENAME

Write final results into FILENAME , JSON formatted.

-m|--mlockall

Call mlockall to lock current and future memory allocations and prevent being paged out

-p|--prompt

Prompt before actually starting the stress test

-q|--quiet

Suppress running output

-r|--rr

Run inversion group threads as SCHED_RR (round-robin). The default is to run the inversion threads as SCHED_FIFO.

-s OPTS|--sched OPTS

scheduling options per thread type:

id=[high|med|low],

policy=[fifo,rr],priority=N,

policy=deadline,runtime=N,deadline=N,period=N

-u|--uniprocessor

Run all threads on one processor. The default is to run all inversion group threads on one processor and the admin threads (reporting thread, keyboard reader, etc.) on a different processor.

-v|--verbose

Run with verbose messages

-V|--version

Print version number

## CAVEATS
The pi_stress test threads run as SCHED_FIFO or SCHED_RR threads, which means that they can starve critical system threads. It is advisable to change the scheduling policy of critical system threads to be SCHED_FIFO prior to running pi_stress and use a priority of 10 or higher, to prevent those threads from being starved by the stress test.

## BUGS
No documented bugs.

## AUTHOR
Clark Williams <williams@redhat.com>


title: pip_stress(8)

text:
# pip_stress(8)

## NAME
pip_stress - Priority Inheritance with processes

## SYNOPSIS
pip_stress

## DESCRIPTION
This program demonstrates the technique of using priority inheritance (PI) mutexes with processes instead of threads. The way to do this is to obtain some shared memory - in this case with mmap that backs a pthread_mutex_t since this will support PI. Pay particular attention to how this is intialized to support processes. Function init_shared_pthread_mutex() does this by setting the pthread_mutexattr to PTHREAD_PROCESS_SHARED and the mutex protocol to PTHREAD_PRIO_INHERIT. In this program we purposely try to invoke a classic priority inversion. A low priority process grabs the mutex and does some work. A high priority process comes a long and is blocked since the mutex is taken. A medium priority process that doesn't require the mutex then takes the processor. Because the processes are restricted to one cpu, the low priority processes never makes any progress because the medium priority process runs in an infinite loop. This is a priority inversion because the medium priority process is running at the expensive of the high priority process. However, since we have used PRIO_INHERIT and are running on a machine that supports preemption, the high priority process will lend it's priority to the low priority process which will preempt the medium priority process. The low priority process will then release the mutex which the high priority process can obtain. When the high priority process gets to run it kills the medium priority process. The state structure keeps track of the progress. Although this program is set up to likely trigger an inversion, there is no guarantee that scheduling will make that happen. After the program completes it reports whether a priority inversion occurred or not. In either case this program demonstrates how to use priority inheritance mutexes with processes. In fact, you would be better off to avoid scenarios in which a priority inversion occurs if possible - this program tries to trigger them just to show that it works. If you are having difficulty triggering an inversion, merely increase the time that the low priority process sleeps while holding the lock. (usleep); Also note that you have to run as a user with permission to change scheduling priorities.

## AUTHOR
pip_stress was written by John Kacur <jkacur at redhat.com>

This manual page was also written by John Kacur


pmqtest

title: pmqtest(8)

text:
# pmqtest(8)

## NAME
pmqtest - Start pairs of threads and measure the latency of interprocess communication with POSIX messages queues

## SYNTAX
pmqtest [-a|-a PROC] [-b USEC] [-d DIST] [-D TIME] [-f TO] [-h] [-i INTV] [--json FILENAME] [-l LOOPS] [-p PRIO] [-q] [-S] [-t|-t NUM]

## DESCRIPTION
The program pmqtest starts pairs of threads that are synchronized via mq_send/mw_receive() and measures the latency between sending and receiving the message.

## OPTIONS
-a, --affinity[=PROC]

Run on processor number PROC. If PROC is not specified, run on current processor.

-b, --breaktrace=USEC

Send break trace command when latency > USEC. This is a debugging option to control the latency tracer in the realtime preemption patch. It is useful to track down unexpected large latencies of a system.

-d, --distance=DIST

Set the distance of thread intervals in microseconds (default is 500 us). When pmqtest is called with the -t option and more than one thread is created, then this distance value is added to the interval of the threads: Interval(thread N) = Interval(thread N-1) + DIST

-D, --duration=TIME

Specify a length for the test run.

Append 'm', 'h', or 'd' to specify minutes, hours or days.

-h, --help

Print help message

-f, --forcetimeout=TO

Set an artificial delay of the send function to force timeout of the receiver, requires the -T option

-i, --interval=INTV

Set the base interval of the thread(s) in microseconds (default is 1000 us). This sets the interval of the first thread. See also -d.

--json=FILENAME

Write final results into FILENAME, JSON formatted.

-l, --loops=LOOPS

Set the number of loops. The default is 0 (endless). This option is useful for automated tests with a given number of test cycles. pmqtest is stopped once the number of timer intervals has been reached.

-p, --prio=PRIO

Set the priority of the process.

-q, --quiet

Print a summary only on exit. Useful for automated tests, where only the summary output needs to be captured.

-S, --smp

Test mode for symmetric multi-processing, implies -a and -t and uses the same priority on all threads.

-t, --threads[=NUM]

Set the number of test threads (default is 1, if this option is not given). If NUM is specified, create NUM test threads. If NUM is not specified, NUM is set to the number of available CPUs.

-T, --timeout=TO

Use mq_timedreceive() instead of mq_receive() and specify timeout TO in seconds.

## EXAMPLES
The following example was running on an 8-way processor:

```
# pmqtest -Sp99 -i100 -d0
#0: ID10047, P99, CPU0, I100; #1: ID10048, P99, CPU0, Cycles 153695
#2: ID10049, P99, CPU1, I100; #3: ID10050, P99, CPU1, Cycles 154211
#4: ID10051, P99, CPU2, I100; #5: ID10052, P99, CPU2, Cycles 156823
#6: ID10053, P99, CPU3, I100; #7: ID10054, P99, CPU3, Cycles 158202
#8: ID10055, P99, CPU4, I100; #9: ID10056, P99, CPU4, Cycles 153399
#10: ID10057, P99, CPU5, I100; #11: ID10058, P99, CPU5, Cycles 153992
#12: ID10059, P99, CPU6, I100; #13: ID10060, P99, CPU6, Cycles 156576
#14: ID10061, P99, CPU7, I100; #15: ID10062, P99, CPU7, Cycles 157957
#1 -> #0, Min    1, Cur    8, Avg    5, Max   18
#3 -> #2, Min    1, Cur    4, Avg    5, Max   18
#5 -> #4, Min    1, Cur    5, Avg    5, Max   19
#7 -> #6, Min    1, Cur    4, Avg    4, Max   17
#9 -> #8, Min    1, Cur    9, Avg    5, Max   18
#11 -> #10, Min    1, Cur    8, Avg    5, Max   18
#13 -> #12, Min    1, Cur    4, Avg    5, Max   29
#15 -> #14, Min    1, Cur    8, Avg    4, Max   17
```

## AUTHORS
Carsten Emde <C.Emde@osadl.org>

## SEE ALSO
mq_send(3p), mq_receive(3p)


ptsematest

title: ptsematest(8)

text:
# ptsematest(8)

## NAME
ptsematest - Start two threads and measure the latency of interprocess communication with POSIX mutex.

## SYNOPSIS
ptsematest [-a|--affinity [PROC]] [-b|--breaktrace USEC] [-d|--distance DIST] [-D|--duration TIME] [-h|--help] [-i|--interval INTV] [--json FILENAME] [-l|--loops LOOPS] [-p|--prio PRIO] [-q|--quiet] [-S|--smp] [-t|--threads [NUM]]

## DESCRIPTION
The program ptsematest starts two threads that are synchronized via pthread_mutex_unlock()/pthread_mutex_lock() and measures the latency between releasing and getting the lock.

## OPTIONS
-a, --affinity[=PROC]

Run on processor number PROC. If PROC is not specified, run on current processor.

-b, --breaktrace=USEC

Send break trace command when latency > USEC. This is a debugging option to control the latency tracer in the realtime preemption patch. It is useful to track down unexpected large latencies of a system.

-d, --distance=DIST

Set the distance of thread intervals in microseconds (default is 500 us). When cyclictest is called with the -t option and more than one thread is created, then this distance value is added to the interval of the threads: Interval(thread N) = Interval(thread N-1) + DIST

-D, --duration=TIME

Specify a length for the test run.

Append 'm', 'h', or 'd' to specify minutes, hours or days.

-h, --help

Print help message.

-i, --interval=INTV

Set the base interval of the thread(s) in microseconds (default is 1000 us). This sets the interval of the first thread. See also -d.

--json=FILENAME

Write final results into FILENAME, JSON formatted.

-l, --loops=LOOPS

Set the number of loops. The default is 0 (endless). This option is useful for automated tests with a given number of test cycles. ptsematest is stopped once the number of timer intervals has been reached.

-p, --prio=PRIO

Set the priority of the process.

-q, --quiet

Print a summary only on exit. Useful for automated tests, where only the summary output needs to be captured.

-S, --smp

SMP testing: options -a -t and same priority

-t, --threads[=NUM]

Set the number of test threads (default is 1, if this option is not given). If NUM is specified, create NUM test threads. If NUM is not specified, NUM is set to the number of available CPUs.

## EXAMPLES
The following example was running on a 4-way processor:

```
# ptsematest -a -t -p99 -i100 -d25 -l1000000
#0: ID8672, P99, CPU0, I100; #1: ID8673, P99, CPU0, Cycles 1000000
#2: ID8674, P98, CPU1, I125; #3: ID8675, P98, CPU1, Cycles 811035
#4: ID8676, P97, CPU2, I150; #5: ID8677, P97, CPU2, Cycles 668130
#6: ID8678, P96, CPU3, I175; #7: ID8679, P96, CPU3, Cycles 589423
#1 -> #0, Min    1, Cur    1, Avg    2, Max   11
#3 -> #2, Min    1, Cur    2, Avg    2, Max   13
#5 -> #4, Min    1, Cur    4, Avg    3, Max   12
#7 -> #6, Min    1, Cur    4, Avg    2, Max   12
```

## AUTHORS
Carsten Emde <C.Emde@osadl.org>

## SEE ALSO
pthread_mutex_lock(3p), pthread_mutex_unlock(3p)


queuelat

title: queuelat(8)

summary: Queue latency test program

text:
# queuelat(8)

## NAME
queuelat - Queue latency test program

## SYNOPSIS
queuelat [-c|--cycles N] [-f|--freq F] [-h|--help] [-m|--max-len LEN] [-p|--packets F] [-q|--queue-len N] [-t|--timeout TIME]

## DESCRIPTION
queuelat simulates a network queue checking for latency violations in packet processing.

## OPTIONS
A summary of options is included below.

-c, --cycles=N

Estimated number of cycles it takes to process one packet. This value should come from the envisioned packet forwarding application being simulated.

-f, --freq=F

TSC frequency in MHz.

-h, --help

Show help

-m, --max-len=N

Maximum allowed latency, in nanoseconds. If latency to process any packet exceeds this value, the program quits, writing a message to the trace buffer.

-p, --packets=F

Million packets per second that arrive for processing.

-q, --queue-len=N

Minimum queue length to print in the trace

-t, --timeout=TIME

Timeout in seconds to quit the program.

## AUTHOR
queuelat was written by Marcelo Tosatti <mtosatti@redhat.com>


rt-migrate-test

title: rt-migrate-test(8)

summary: real-time task migration program

text:
# rt-migrate-test(8)

## NAME
rt-migrate-test - real-time task migration program

## SYNOPSIS
rt-migrate-test [-c|--check] [-D|--duration TIME] [-e|--equal] [-h|--help] [--json FILENAME] [-l|--loops LOOPS] [-m|--maxerr TIME] [-p|--prio PRIO] [-r|--run-time TIME] [-s|--sleep-time TIME] [NR_TASKS]

## DESCRIPTION
Test real-time multiprocessor scheduling of tasks to ensure the highest priority tasks are running on all available CPUs

## OPTIONS
This program follows the usual GNU command line syntax, with long options starting with two dashes ('--').

In the summary of options, a value in brackets (), indicates a default value

-c, --check

Stop if lower prio task is quicker than higher (off)

-D, --duration=TIME

Specify a length for the test run.

Append 'm', 'h', or 'd' to specify minutes, hours or days.

-e, --equal

Use equal prio for #CPU-1 tasks (requires > 2 CPUS)

-h, --help

Display usage

--json=FILENAME

Write final results into FILENAME, JSON formatted.

-l --loops=LOOPS

Number of iterations to run (50)

-m, --maxerr=TIME

Max allowed error (microsecs)

-p, --prio=PRIO

base priority to start RT tasks with (2)

-r, --run-time=TIME

Run time (ms) to busy loop the threads (20)

-s, --sleep-time=TIME

Sleep time (ms) between intervals (100)

[NR_TASKS]

number of tasks to run (number of cpus + 1)

## AUTHOR
rt-migrate-test was written by Steven Rostedt <srostedt@redhat.com>

This manual page was written by John Kacur <jkacur@redhat.com>


signaltest

title: signaltest(8)

summary: signal roundtrip test software

text:
# signaltest(8)

## NAME
signaltest - signal roundtrip test software

## SYNOPSIS
signaltest [ -a|--affinity NUM] [ -b|--backtrace USEC ] [-D|--duration TIME] [-h|--help] [--json FILENAME] [-l|--loops LOOPS ] [-p|--prio PRIO] [-q|--quiet] [-S|--smp] [-t|--threads NUM] [-m|--mlockall ] [-v|--verbose ]

## OPTIONS
These programs follow the usual GNU command line syntax, with long options starting with two dashes ('--').

-a, --affinity[=PROC-SET]

Run threads on the set of processors given by PROC-SET. If PROC-SET is not specified, all processors will be used. Threads will be assigned to processors in the set in numeric order, in a round-robin fashion.

The set of processors can be specified as A,B,C, or A-C, or A-B,D-F, and so on*. The ! character can be used to negate a set. For example, !B-D means to use all available CPUs except B through D. The cpu numbers are the same as shown in the processor field in /proc/cpuinfo. See numa(3) for more information on specifying CPU sets. * Support for CPU sets requires libnuma version >= 2. For libnuma v1, PROC-SET, if specified, must be a single CPU number.

-b, --breaktrace=USEC

Send break trace command when latency > USEC

-D, --duration=TIME

Specify a length for the test run.

Append 'm', 'h', or 'd' to specify minutes, hours or days.

--help

display usage information

--json=FILENAME

Write final results into FILENAME, JSON formatted.

-l, --loops=LOOPS

Number of loops: default=0 (endless)

-p, --priority=PRIO

Priority of highest priority thread

-q, --quiet

print a summary only on exit

-S, --smp

Set options for standard testing on SMP systems. Equivalent to using the options: "-t -a" as well keeping any specified priority equal across all threads

-t, --threads=NUM

number of threads: default=2

-m, --mlockall

lock current and future memory allocations

-v, --verbose

output values on stdout for statistics

format: n:c:v n=tasknum c=count v=value in us

## AUTHOR
signaltest was written by Thomas Gleixner <tglx@linuxtronix.de>.

This manual page was originally written by

John Kacur <jkacur@redhat.com>

Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. This file is offered as-is, without any warranty.


sigwaittest

title: sigwaittest(8)

text:
# sigwaittest(8)

## NAME
sigwaittest - Start two threads or fork two processes and measure the latency between sending and receiving a signal

## SYNTAX
sigwaittest [-a|--affinity PROC] [-b|--breaktrace USEC] [-d|--distance DIST] [-D|--duration TIME] [-f|--fork [OPT]] [-i|--interval INTV] [--json FILENAME] [-l|--loops LOOPS] [-p|--prio PRIO] [-t|--threads [NUM]]

## DESCRIPTION
The program sigwaittest starts two threads or, optionally, forks two processes that are synchronized via signals and measures the latency between sending a signal and returning from sigwait().

## OPTIONS
-a, --affinity[=PROC]

Run on processor number PROC. If PROC is not specified, run on current processor.

-b, --breaktrace=USEC

Send break trace command when latency > USEC. This is a debugging option to control the latency tracer in the realtime preemption patch. It is useful to track down unexpected large latencies of a system.

-d, --distance=DIST

Set the distance of thread intervals in microseconds (default is 500 us). When cyclictest is called with the -t option and more than one thread is created, then this distance value is added to the interval of the threads: Interval(thread N) = Interval(thread N-1) + DIST

-D, --duration=TIME

Specify a length for the test run.

Append 'm', 'h', or 'd' to specify minutes, hours or days.

-f, --fork[=OPT]

Instead of creating threads (which is the default), fork new processes

-i, --interval=INTV

Set the base interval of the thread(s) in microseconds (default is 1000 us). This sets the interval of the first thread. See also -d.

--json=FILENAME

Write final results into FILENAME, JSON formatted.

-l, --loops=LOOPS

Set the number of loops. The default is 0 (endless). This option is useful for automated tests with a given number of test cycles. sigwaittest is stopped once the number of timer intervals has been reached.

-p, --prio=PRIO

Set the priority of the process.

-t, --threads[=NUM]

Set the number of test threads (default is 1, if this option is not given). If NUM is specified, create NUM test threads. If NUM is not specified, NUM is set to the number of available CPUs.

## EXAMPLES
The following example was running on a 4-way CPU:

```
# sigwaittest -a -t -p99 -i100 -d25 -l1000000
#0: ID11510, P99, CPU0, I100; #1: ID11511, P99, CPU0, Cycles 1000000
#2: ID11512, P98, CPU1, I125; #3: ID11513, P98, CPU1, Cycles 817484
#4: ID11514, P97, CPU2, I150; #5: ID11515, P97, CPU2, Cycles 668213
#6: ID11516, P96, CPU3, I175; #7: ID11517, P96, CPU3, Cycles 597344
#1 -> #0, Min    1, Cur    2, Avg    3, Max   30
#3 -> #2, Min    1, Cur   26, Avg    3, Max   42
#5 -> #4, Min    1, Cur   46, Avg    4, Max   67
#7 -> #6, Min    1, Cur    2, Avg    3, Max   74
```

## AUTHORS
Carsten Emde <C.Emde@osadl.org>

## SEE ALSO
kill(2), sigwait(3)


ssdd

title: ssdd(8)

text:
# ssdd(8)

## NAME
ssdd - have a tracer do a bunch of PTRACE_SINGLESTEPs

## SYNOPSIS
ssdd [-f|--forks NUM] [-h|--help] [-i|--iters NUM] [--json FILENAME]

## DESCRIPTION
Have a tracer do a bunch of PTRACE_SINGLESTEPs against a tracee as fast as possible. Create several of these tracer/tracee pairs and see if they can be made to interfere with each other. The tracer waits on each PTRACE_SINGLESTEP with a waitpid(2) and checks that waitpid's return values for correctness.

## OPTIONS
-f, --forks=NUM

number of tracer/tracee pairs to fork off.

Default is 10.

-h, --help

Display usage

-i, --iters=NUM

number of PTRACE_SINGLESTEP iterations to do before declaring success, for each tracer tracee pair set up.

Default is 10,000.

--json=FILENAME

Write final results into FILENAME, JSON formatted.

## AUTHOR
ssdd was written by Joe Korty <joe.korty@concurrent-rt.com>

This manual page was written by John Kacur <jkacur@redhat.com>


svsematest

title: svsematest(8)

text:
# svsematest(8)

## NAME
svsematest - Start two threads or fork two processes and measure the latency of SYSV semaphores

## SYNTAX
svsematest [-a|--affinity NUM] [-b|--breaktrace USEC] [-d|--distance DIST] [-D|--duration TIME] [-f|--fork [OPT]] [-i|--interval INTV] [--json FILENAME] [-l|--loops LOOPS] [-p|--prio PRIO] [-q|--quiet] [-S|--smp] [-t|--threads [NUM]]

## DESCRIPTION
The program svsematest starts two threads or, optionally, forks two processes that are synchronized via SYSV semaphores and measures the latency between releasing a semaphore on one side and getting it on the other side.

## OPTIONS
-a, --affinity[=NUM]

Run on processor number NUM. If PROC is not specified, run on current processor.

-b, --breaktrace=USEC

Send break trace command when latency > USEC. This is a debugging option to control the latency tracer in the realtime preemption patch. It is useful to track down unexpected large latencies of a system.

-d, --distance=DIST

Set the distance of thread intervals in microseconds (default is 500 us). When cyclictest is called with the -t option and more than one thread is created, then this distance value is added to the interval of the threads: Interval(thread N) = Interval(thread N-1) + DIST

-D, --duration=TIME

Specify a length for the test run.

Append 'm', 'h', or 'd' to specify minutes, hours or days.

-f, --fork

Instead of creating threads (which is the default), fork new processes

-i, --interval=INTV

Set the base interval of the thread(s) in microseconds (default is 1000 us). This sets the interval of the first thread. See also -d.

--json=FILENAME

Write final results into FILENAME, JSON formatted.

-l, --loops=LOOPS

Set the number of loops. The default is 0 (endless). This option is useful for automated tests with a given number of test cycles. svsematest is stopped once the number of timer intervals has been reached.

-p, --prio=PRIO

Set the priority of the process.

-q, --quiet

Print a summary only on exit. Useful for automated tests, where only the summary output needs to be captured.

-S, --smp

SMP testing: options -a -t and same priority of all threads

-t, --threads[=NUM]

Set the number of test threads (default is 1, if this option is not given). If NUM is specified, create NUM test threads. If NUM is not specified, NUM is set to the number of available CPUs.

## EXAMPLES
The following example was running on a 4-way CPU:

```
# svsematest -a -t -p99 -i100 -d25 -l1000000
#0: ID13110, P99, CPU0, I100; #1: ID13111, P99, CPU0, Cycles 1000000
#2: ID13112, P98, CPU1, I125; #3: ID13113, P98, CPU1, Cycles 813573
#4: ID13114, P97, CPU2, I150; #5: ID13115, P97, CPU2, Cycles 667285
#6: ID13116, P96, CPU3, I175; #7: ID13117, P96, CPU3, Cycles 591403
#1 -> #0, Min    1, Cur    2, Avg    2, Max   12
#3 -> #2, Min    1, Cur    3, Avg    2, Max   12
#5 -> #4, Min    1, Cur    3, Avg    3, Max   12
#7 -> #6, Min    1, Cur    2, Avg    3, Max   11
```

## AUTHORS
Carsten Emde <C.Emde@osadl.org>

## SEE ALSO
semop(2)


acpidump-linux

package: linux-tools

title: acpidump-linux(8)

text:
# acpidump-linux(8)

## NAME
acpidump - dump a system's ACPI tables to an ASCII file

## SYNOPSIS
acpidump [options]

## DESCRIPTION
acpidump dumps the systems ACPI tables to an ASCII file appropriate for attaching to a bug report.

Subsequently, they can be processed by utilities in the ACPICA package.

## OPTIONS
acpidump options are as follow:

Options

-b

Dump tables to binary files

-h -?

This help message

-o <File>

Redirect output to file

-r <Address>

Dump tables from specified RSDP

-s

Print table summaries only

-v

Display version information

-z

Verbose mode

Table Options

-a <Address>

Get table via a physical address

-c <on|off>

Turning on/off customized table dumping

-f <BinaryFile>

Get table via a binary file

-n <Signature>

Get table via a name/signature

-x

Do not use but dump XSDT

-x -x

Do not use or dump XSDT

Invocation without parameters dumps all available tables.

Multiple mixed instances of -a, -f, and -n are supported.

## EXAMPLES

```
# acpidump > acpidump.out
$ acpixtract -a acpidump.out

        Acpi table [DSDT] -  15974 bytes written to DSDT.dat

        Acpi table [FACS] -     64 bytes written to FACS.dat

        Acpi table [FACP] -    116 bytes written to FACP.dat

        Acpi table [APIC] -    120 bytes written to APIC.dat

        Acpi table [MCFG] -     60 bytes written to MCFG.dat

        Acpi table [SSDT] -    444 bytes written to SSDT1.dat

        Acpi table [SSDT] -    439 bytes written to SSDT2.dat

        Acpi table [SSDT] -    439 bytes written to SSDT3.dat

        Acpi table [SSDT] -    439 bytes written to SSDT4.dat

        Acpi table [SSDT] -    439 bytes written to SSDT5.dat

        Acpi table [RSDT] -     76 bytes written to RSDT.dat

        Acpi table [RSDP] -     20 bytes written to RSDP.dat
$ iasl -d *.dat
```

creates *.dsl, a human readable form which can be edited and compiled using iasl.

## NOTES
acpidump must be run as root.

## REFERENCES
ACPICA: https://acpica.org/

## FILES

```
/dev/mem
/sys/firmware/acpi/tables/*
/sys/firmware/acpi/tables/dynamic/*
/sys/firmware/efi/systab
```

## AUTHOR
Original by:

Len Brown <len.brown@intel.com>

Written by:

Chao Guan <chao.guan@intel.com>

Updated by:

Bob Moore <robert.moore@intel.com>

Lv Zheng <lv.zheng@intel.com>

## SEE ALSO
acpixtract(8), iasl(8).

## COPYRIGHT
COPYRIGHT (c) 2013, Intel Corporation.


pfrut

title: pfrut(8)

text:
# pfrut(8)

## Name
pfrut - Platform Firmware Runtime Update and Telemetry tool

## SYNOPSIS
pfrut [Options]

## DESCRIPTION
The PFRUT(Platform Firmware Runtime Update and Telemetry) kernel interface is designed to

interact with the platform firmware interface defined in the

Management Mode Firmware Runtime Update (https://uefi.org/sites/default/files/resources/Intel_MM_OS_Interface_Spec_Rev100.pdf)

pfrut is the tool to interact with the kernel interface.

## OPTIONS
-h, --help

Display helper information.

-l, --load

Load the capsule file into the system. To be more specific, the capsule file will be copied to the communication buffer.

-s, --stage

Stage the capsule image from communication buffer into Management Mode and perform authentication.

-a, --activate

Activate a previous staged capsule image.

-u, --update

Perform both stage and activation actions.

-q, --query

Query the update capability.

-d, --setrev

Set the revision ID of code injection/driver update.

-D, --setrevlog

Set the revision ID of telemetry.

-G, --getloginfo

Get telemetry log information and print it out.

-T, --type

Set the telemetry log data type.

-L, --level

Set the telemetry log level.

-R, --read

Read all the telemetry data and print it out.

## EXAMPLES
pfrut -G

log_level:4

log_type:0

log_revid:2

max_data_size:65536

chunk1_size:0

chunk2_size:1401

rollover_cnt:0

reset_cnt:4

pfru -q

code injection image type:794bf8b2-6e7b-454e-885f-3fb9bb185402

fw_version:0

code_rt_version:1

driver update image type:0e5f0b14-f849-7945-ad81-bc7b6d2bb245

drv_rt_version:0

drv_svn:0

platform id:39214663-b1a8-4eaa-9024-f2bb53ea4723

oem id:a36db54f-ea2a-e14e-b7c4-b5780e51ba3d

pfrut -l yours.cap -u -T 1 -L 4

## AUTHORS
Chen Yu.


tmon

title: tmon(8)

text:
# tmon(8)

# SPDX-License-Identifier: GPL-2.0

## NAME
tmon - A monitoring and testing tool for Linux kernel thermal subsystem

## SYNOPSIS
tmon [Options]

## DESCRIPTION
tmon can be used to visualize thermal relationship and real-time thermal data; tune and test cooling devices and sensors; collect thermal data for offline analysis and plot. tmon must be run as root in order to control device states via sysfs.

Functions

```
1. Thermal relationships:
- show thermal zone information
- show cooling device information
- show trip point binding within each thermal zone
- show trip point and cooling device instance bindings
```

```
2. Real time data display
- show temperature of all thermal zones w.r.t. its trip points and types
- show states of all cooling devices
```

```
3. Thermal relationship learning and device tuning
- with a built-in Proportional Integral Derivative (PID)
controller, user can pair a cooling device to a thermal sensor for
testing the effectiveness and learn about the thermal distance between the two
- allow manual control of cooling device states and target temperature
```

```
4. Data logging in /var/tmp/tmon.log
- contains thermal configuration data, i.e. cooling device, thermal

 zones, and trip points. Can be used for data  collection in remote

 debugging.
- log real-time thermal data into space separated format that can be

 directly consumed by plotting tools such as Rscript.
```

### Options
The -c --control option sets a cooling device type to control temperature of a thermal zone

The -d --daemon option runs tmon as daemon without user interface

The -g --debug option allow debug messages to be stored in syslog

The -h --help option shows help message

The -l --log option write data to /var/tmp/tmon.log

The -t --time-interval option sets the polling interval in seconds

The -T --target-temp option sets the initial target temperature

The -v --version option shows the version of tmon

The -z --zone option sets the target therma zone instance to be controlled

## FIELD DESCRIPTIONS

```
P  passive cooling trip point type
A  active cooling trip point type (fan)
C  critical trip point type
A  hot trip point type
kp  proportional gain of PID controller
ki  integral gain of PID controller
kd  derivative gain of PID controller
```

## REQUIREMENT
Build depends on ncurses

Runtime depends on window size large enough to show the number of devices found on the system.

## INTERACTIVE COMMANDS

```
Ctrl-C, q/Q stops tmon
TAB shows tuning pop up panel, choose a letter to modify
```

## EXAMPLES
Without any parameters, tmon is in monitoring only mode and refresh screen every 1 second.

1. For monitoring only:

```
$ sudo ./tmon
2. Use Processor cooling device to control thermal zone 0 at default 65C.
$ sudo ./tmon -c Processor -z 0
3. Use intel_powerclamp(idle injection) cooling device to control thermal zone 1
$ sudo ./tmon -c intel_powerclamp -z 1
4. Turn on debug and collect data log at /var/tmp/tmon.log
$ sudo ./tmon -g -l
For example, the log below shows PID controller was adjusting current states
for all cooling devices with "Processor" type such that thermal zone 0
can stay below 65 dC.
#---------- THERMAL DATA LOG STARTED -----------
Samples TargetTemp acpitz0    acpitz1    Fan0 Fan1 Fan2 Fan3 Fan4 Fan5
Fan6 Fan7 Fan8 Fan9 Processor10 Processor11 Processor12 Processor13
LCD14 intel_powerclamp15 1 65.0 65 65 0 0 0 0 0 0 0 0 0 0 0 0 0 0 6 0 2
65.0 66 65 0 0 0 0 0 0 0 0 0 0 4 4 4 4 6 0 3 65.0 60 54 0 0 0 0 0 0 0 0
0 0 4 4 4 4 6 0 4 65.0 53 53 0 0 0 0 0 0 0 0 0 0 4 4 4 4 6 0
5 65.0 52 52 0 0 0 0 0 0 0 0 0 0 0 0 0 0 6 0
6 65.0 53 65 0 0 0 0 0 0 0 0 0 0 0 0 0 0 6 0
7 65.0 68 70 0 0 0 0 0 0 0 0 0 0 0 0 0 0 6 0
8 65.0 68 68 0 0 0 0 0 0 0 0 0 0 5 5 5 5 6 0
9 65.0 68 68 0 0 0 0 0 0 0 0 0 0 6 6 6 6 6 0
10 65.0 67 67 0 0 0 0 0 0 0 0 0 0 7 7 7 7 6 0
11 65.0 67 67 0 0 0 0 0 0 0 0 0 0 8 8 8 8 6 0
12 65.0 67 67 0 0 0 0 0 0 0 0 0 0 8 8 8 8 6 0
13 65.0 67 67 0 0 0 0 0 0 0 0 0 0 9 9 9 9 6 0
14 65.0 66 66 0 0 0 0 0 0 0 0 0 0 10 10 10 10 6 0
15 65.0 66 67 0 0 0 0 0 0 0 0 0 0 10 10 10 10 6 0
16 65.0 66 66 0 0 0 0 0 0 0 0 0 0 11 11 11 11 6 0
17 65.0 66 66 0 0 0 0 0 0 0 0 0 0 11 11 11 11 6 0
18 65.0 64 61 0 0 0 0 0 0 0 0 0 0 11 11 11 11 6 0
19 65.0 60 59 0 0 0 0 0 0 0 0 0 0 12 12 12 12 6 0
Data can be read directly into an array by an example R-script below:
#!/usr/bin/Rscript
tdata <- read.table("/var/tmp/tmon.log", header=T, comment.char="#")
attach(tdata)
jpeg("tmon.jpg")
X11()
g_range <- range(0, intel_powerclamp15, TargetTemp, acpitz0)
plot( Samples, intel_powerclamp15, col="blue", ylim=g_range, axes=FALSE, ann=FALSE)
par(new=TRUE)
lines(TargetTemp, type="o", pch=22, lty=2, col="red")
dev.off()
```


package: linuxptp

title: hwstamp_ctl(8)

text:
# hwstamp_ctl(8)

## NAME
hwstamp_ctl - set time stamping policy at the driver level

## SYNOPSIS
hwstamp_ctl -i interface [ -r rx-filter ] [ -t tx-type ] [ -v ]

## DESCRIPTION
hwstamp_ctl is a program used to set and get the hardware time stamping policy at the network driver level with the SIOCSHWTSTAMP ioctl(2). The tx-type and rx-filter values are hints to the driver what it is expected to do. If the requested fine-grained filtering for incoming packets is not supported, the driver may time stamp more than just the requested types of packets.

If neither tx-type nor rx-filter values are passed to the program, it will use the SIOCGHWTSTAMP ioctl(2) to non-destructively read the current hardware time stamping policy.

This program is a debugging tool. The ptp4l(8) program does not need this program to function, it will set the policy automatically as appropriate.

## OPTIONS
-i interface

Specify the network interface of which the policy should be changed.

-r rx-filter

Specify which types of incoming packets should be time stamped, rx-filter is an integer value.

-t tx-type

Enable or disable hardware time stamping for outgoing packets, tx-type is an integer value.

-h

Display a help message and list of possible values for rx-filter and tx-type.

-v

Prints the software version and exits.

## SEE ALSO
ioctl(2), ptp4l(8)


nsm

title: nsm(8)

summary: NetSync Monitor client

text:
# nsm(8)

## NAME
nsm - NetSync Monitor client

## SYNOPSIS
nsm [ -f config ] [ -i interface ] [ long-options ] [ command ] ...

## DESCRIPTION
nsm is a program which implements a NetSync Monitor (NSM) client. NSM is an extension to the Precision Time Protocol (PTP), which enables a client to measure the offset of its clock against any PTP clock in the network which supports NSM. It uses unicast messages, but unlike PTP in the unicast mode it does not require the server to keep any state specific to the client. It is particularly useful for monitoring.

The program reads commands from the standard input or from the command line.

## COMMANDS
NSM address

Send a NetSync Monitor request to the specified network address (IPv4 or MAC) and print the measured offset with the response.

help

Display a help message.

## OPTIONS
-f config

Read configuration from the specified file. No configuration file is read by default.

-i interface

Specify the network interface.

-h

Display a help message.

-v

Print the software version and exit.

## LONG OPTIONS
Each and every configuration file option (see below in sections PROGRAM OPTIONS and PORT OPTIONS) may also appear as a "long" style command line argument. For example, the transportSpecific option may be set using either of these two forms:

--transportSpecific 1 --transportSpecific=1

Option values given on the command line override values in the global section of the configuration file (which, in turn, overrides default values).

## CONFIGURATION FILE
The configuration file is divided into sections. Each section starts with a line containing its name enclosed in brackets and it follows with settings. Each setting is placed on a separate line, it contains the name of the option and the value separated by whitespace characters. Empty lines and lines starting with # are ignored.

The global section (indicated as [global]) sets the global program options as well as the default port specific options. Other sections are port specific sections and they override the default port options. The name of the section is the name of the configured port (e.g. [eth0] ).

## PORT OPTIONS
delayAsymmetry

The time difference in nanoseconds of the transmit and receive paths. This value should be positive when the master-to-slave propagation time is longer and negative when the slave-to-master time is longer. The default is 0 nanoseconds.

network_transport

Select the network transport. Possible values are UDPv4 and L2. The default is UDPv4.

transportSpecific

The transport specific field. Must be in the range 0 to 255. The default is 0.

## PROGRAM OPTIONS
domainNumber

The domain attribute of the local clock. The default is 0. time_stamping The time stamping method. The allowed values are hardware, software and legacy. The default is hardware.

## WARNING
Be cautious when the same configuration file is used for both ptp4l and nsm. Keep in mind that values specified in the configuration file take precedence over their default values. If a certain option which is common to ptp4l and nsm is specified to a non-default value in the configuration file (e.g. for ptp4l), then this non-default value applies also for nsm. This might be not what is expected.

To avoid securely these unexpected behaviour, different configuration files for ptp4l and nsm are recommended.

## SEE ALSO
ptp4l(8)