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

(c)1994-2000 Larry McVoy and Carl Staelin            $Date$                                           LMBENCH(8)