# PaCkAgE DaTaStReAm netperf 1 1837 # end of header 0707010003bb95000081a40000000000000000000000014f45c9f10000010a000000b500010002ffffffffffffffff0000001000000000netperf/pkginfoPKG=netperf NAME=netperf 2.5.0 i86pc Solaris 10 VERSION=2.5.0 PSTAMP=23rd February 2012 VENDOR=Hewlett-Packard EMAIL=http://www.netperf.org/netperf/ DESC=Network benchmarking tool ARCH=i386 CATEGORY=utility CLASSES=none BASEDIR=/ ISTATES=S s 1 2 3 RSTATES=S s 1 2 3 0707010003bb94000081a40000000000000000000000014f45c9f100000496000000b500010002ffffffffffffffff0000000f00000000netperf/pkgmap: 1 1837 1 d none /usr ? ? ? 1 d none /usr/local ? ? ? 1 d none /usr/local/bin 0755 root root 1 f none /usr/local/bin/netperf 0755 root root 200328 115 1329971530 1 f none /usr/local/bin/netserver 0755 root root 210692 4915 1329971530 1 d none /usr/local/share/doc 0755 root root 1 d none /usr/local/share/doc/netperf 0755 root root 1 f none /usr/local/share/doc/netperf/AUTHORS 0644 root root 7224 55450 1329972430 1 f none /usr/local/share/doc/netperf/COPYING 0644 root root 2079 29230 1329972430 1 f none /usr/local/share/doc/netperf/ChangeLog 0644 root root 27 2485 1329972430 1 f none /usr/local/share/doc/netperf/Release_Notes 0644 root root 42958 3245 1329972430 1 f none /usr/local/share/doc/netperf/netperf.html 0644 root root 241261 38019 1329972363 1 d none /usr/local/share/info 0755 root root 1 f none /usr/local/share/info/netperf.info 0644 root root 185601 61558 1329971530 1 d none /usr/local/share/man/man1 0755 root root 1 f none /usr/local/share/man/man1/netperf.1 0644 root root 7204 39257 1329971531 1 f none /usr/local/share/man/man1/netserver.1 0644 root root 1617 7547 1329971531 1 i checkinstall 790 2504 1329973745 1 i pkginfo 266 20824 1329973745 07070100000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000b00000000TRAILER!!!0707010003bb95000081a40000000000000000000000014f45c9f10000010a000000b500010002ffffffffffffffff0000000800000000pkginfoPKG=netperf NAME=netperf 2.5.0 i86pc Solaris 10 VERSION=2.5.0 PSTAMP=23rd February 2012 VENDOR=Hewlett-Packard EMAIL=http://www.netperf.org/netperf/ DESC=Network benchmarking tool ARCH=i386 CATEGORY=utility CLASSES=none BASEDIR=/ ISTATES=S s 1 2 3 RSTATES=S s 1 2 3 0707010003bb94000081a40000000000000000000000014f45c9f100000496000000b500010002ffffffffffffffff0000000700000000pkgmap: 1 1837 1 d none /usr ? ? ? 1 d none /usr/local ? ? ? 1 d none /usr/local/bin 0755 root root 1 f none /usr/local/bin/netperf 0755 root root 200328 115 1329971530 1 f none /usr/local/bin/netserver 0755 root root 210692 4915 1329971530 1 d none /usr/local/share/doc 0755 root root 1 d none /usr/local/share/doc/netperf 0755 root root 1 f none /usr/local/share/doc/netperf/AUTHORS 0644 root root 7224 55450 1329972430 1 f none /usr/local/share/doc/netperf/COPYING 0644 root root 2079 29230 1329972430 1 f none /usr/local/share/doc/netperf/ChangeLog 0644 root root 27 2485 1329972430 1 f none /usr/local/share/doc/netperf/Release_Notes 0644 root root 42958 3245 1329972430 1 f none /usr/local/share/doc/netperf/netperf.html 0644 root root 241261 38019 1329972363 1 d none /usr/local/share/info 0755 root root 1 f none /usr/local/share/info/netperf.info 0644 root root 185601 61558 1329971530 1 d none /usr/local/share/man/man1 0755 root root 1 f none /usr/local/share/man/man1/netperf.1 0644 root root 7204 39257 1329971531 1 f none /usr/local/share/man/man1/netserver.1 0644 root root 1617 7547 1329971531 1 i checkinstall 790 2504 1329973745 1 i pkginfo 266 20824 1329973745 0707010003bbaa000041ed0000000000000000000000024f45c9f100000000000000b500010002ffffffffffffffff0000000800000000install0707010003bbab000081ed0000000000000000000000014f45c9f100000316000000b500010002ffffffffffffffff0000001500000000install/checkinstall#!/bin/sh # expected_bits="64" expected_release="5.10" expected_platform="i386" # release=`uname -r` platform=`uname -p` bits=`isainfo -b` # if [ ${platform} != ${expected_platform} ]; then echo "\n\n\n\tThis package must be installed on a ${expected_platform} architecture\n" echo "\tAborting installation.\n\n\n" exit 1 fi if [ ${release} != ${expected_release} ]; then echo "\n\n\n\tThis package must be installed on a ${expected_release} machine\n" echo "\tAborting installation.\n\n\n" exit 1 fi #if [ ${bits} != ${expected_bits} ]; then # echo "\n\n\n\tThis package must be installed on a ${expected_bits} bit machine\n" # echo "\tYour machine is running a ${bits} bit O.S. currently\n" # echo "\tAborting installation.\n\n\n" # exit 1 #fi exit 0 0707010003bb96000041ed0000000000000000000000034f45c9f100000000000000b500010002ffffffffffffffff0000000500000000root0707010003bb97000041ed0000000000000000000000034f45c9f100000000000000b500010002ffffffffffffffff0000000900000000root/usr0707010003bb98000041ed0000000000000000000000044f45c9f100000000000000b500010002ffffffffffffffff0000000f00000000root/usr/local0707010003bb9c000041ed0000000000000000000000054f45c9f100000000000000b500010002ffffffffffffffff0000001500000000root/usr/local/share0707010003bb9d000041ed0000000000000000000000034f45c9f100000000000000b500010002ffffffffffffffff0000001900000000root/usr/local/share/doc0707010003bb9e000041ed0000000000000000000000024f45c9f100000000000000b500010002ffffffffffffffff0000002100000000root/usr/local/share/doc/netperf0707010003bba3000081a40000000000000000000000014f45c48b0003ae6d000000b500010002ffffffffffffffff0000002e00000000root/usr/local/share/doc/netperf/netperf.html Care and Feeding of Netperf 2.5.X

Care and Feeding of Netperf 2.5.X

Table of Contents


Next: , Previous: (dir), Up: (dir)

Netperf Manual

This is Rick Jones' feeble attempt at a Texinfo-based manual for the netperf benchmark.

Copyright © 2005-2011 Hewlett-Packard Company

Permission is granted to copy, distribute and/or modify this document per the terms of the netperf source licence, a copy of which can be found in the file COPYING of the basic netperf distribution.


Next: , Previous: Top, Up: Top

1 Introduction

Netperf is a benchmark that can be use to measure various aspect of networking performance. The primary foci are bulk (aka unidirectional) data transfer and request/response performance using either TCP or UDP and the Berkeley Sockets interface. As of this writing, the tests available either unconditionally or conditionally include:

While not every revision of netperf will work on every platform listed, the intention is that at least some version of netperf will work on the following platforms:

Netperf is maintained and informally supported primarily by Rick Jones, who can perhaps be best described as Netperf Contributing Editor. Non-trivial and very appreciated assistance comes from others in the network performance community, who are too numerous to mention here. While it is often used by them, netperf is NOT supported via any of the formal Hewlett-Packard support channels. You should feel free to make enhancements and modifications to netperf to suit your nefarious porpoises, so long as you stay within the guidelines of the netperf copyright. If you feel so inclined, you can send your changes to netperf-feedback for possible inclusion into subsequent versions of netperf.

It is the Contributing Editor's belief that the netperf license walks like open source and talks like open source. However, the license was never submitted for “certification” as an open source license. If you would prefer to make contributions to a networking benchmark using a certified open source license, please consider netperf4, which is distributed under the terms of the GPLv2.

The netperf-talk mailing list is available to discuss the care and feeding of netperf with others who share your interest in network performance benchmarking. The netperf-talk mailing list is a closed list (to deal with spam) and you must first subscribe by sending email to netperf-talk-request.


Previous: Introduction, Up: Introduction

1.1 Conventions

A sizespec is a one or two item, comma-separated list used as an argument to a command-line option that can set one or two, related netperf parameters. If you wish to set both parameters to separate values, items should be separated by a comma:

     parameter1,parameter2

If you wish to set the first parameter without altering the value of the second from its default, you should follow the first item with a comma:

     parameter1,

Likewise, precede the item with a comma if you wish to set only the second parameter:

     ,parameter2

An item with no commas:

     parameter1and2

will set both parameters to the same value. This last mode is one of the most frequently used.

There is another variant of the comma-separated, two-item list called a optionspec which is like a sizespec with the exception that a single item with no comma:

     parameter1

will only set the value of the first parameter and will leave the second parameter at its default value.

Netperf has two types of command-line options. The first are global command line options. They are essentially any option not tied to a particular test or group of tests. An example of a global command-line option is the one which sets the test type - -t.

The second type of options are test-specific options. These are options which are only applicable to a particular test or set of tests. An example of a test-specific option would be the send socket buffer size for a TCP_STREAM test.

Global command-line options are specified first with test-specific options following after a -- as in:

     netperf <global> -- <test-specific>


Next: , Previous: Introduction, Up: Top

2 Installing Netperf

Netperf's primary form of distribution is source code. This allows installation on systems other than those to which the authors have ready access and thus the ability to create binaries. There are two styles of netperf installation. The first runs the netperf server program - netserver - as a child of inetd. This requires the installer to have sufficient privileges to edit the files /etc/services and /etc/inetd.conf or their platform-specific equivalents.

The second style is to run netserver as a standalone daemon. This second method does not require edit privileges on /etc/services and /etc/inetd.conf but does mean you must remember to run the netserver program explicitly after every system reboot.

This manual assumes that those wishing to measure networking performance already know how to use anonymous FTP and/or a web browser. It is also expected that you have at least a passing familiarity with the networking protocols and interfaces involved. In all honesty, if you do not have such familiarity, likely as not you have some experience to gain before attempting network performance measurements. The excellent texts by authors such as Stevens, Fenner and Rudoff and/or Stallings would be good starting points. There are likely other excellent sources out there as well.


Next: , Previous: Installing Netperf, Up: Installing Netperf

2.1 Getting Netperf Bits

Gzipped tar files of netperf sources can be retrieved via anonymous FTP for “released” versions of the bits. Pre-release versions of the bits can be retrieved via anonymous FTP from the experimental subdirectory.

For convenience and ease of remembering, a link to the download site is provided via the NetperfPage

The bits corresponding to each discrete release of netperf are tagged for retrieval via subversion. For example, there is a tag for the first version corresponding to this version of the manual - netperf 2.5.0. Those wishing to be on the bleeding edge of netperf development can use subversion to grab the top of trunk. When fixing bugs or making enhancements, patches against the top-of-trunk are preferred.

There are likely other places around the Internet from which one can download netperf bits. These may be simple mirrors of the main netperf site, or they may be local variants on netperf. As with anything one downloads from the Internet, take care to make sure it is what you really wanted and isn't some malicious Trojan or whatnot. Caveat downloader.

As a general rule, binaries of netperf and netserver are not distributed from ftp.netperf.org. From time to time a kind soul or souls has packaged netperf as a Debian package available via the apt-get mechanism or as an RPM. I would be most interested in learning how to enhance the makefiles to make that easier for people.


Next: , Previous: Getting Netperf Bits, Up: Installing Netperf

2.2 Installing Netperf

Once you have downloaded the tar file of netperf sources onto your system(s), it is necessary to unpack the tar file, cd to the netperf directory, run configure and then make. Most of the time it should be sufficient to just:

     gzcat netperf-<version>.tar.gz | tar xf -
     cd netperf-<version>
     ./configure
     make
     make install

Most of the “usual” configure script options should be present dealing with where to install binaries and whatnot.

     ./configure --help

should list all of those and more. You may find the --prefix option helpful in deciding where the binaries and such will be put during the make install.

If the netperf configure script does not know how to automagically detect which CPU utilization mechanism to use on your platform you may want to add a --enable-cpuutil=mumble option to the configure command. If you have knowledge and/or experience to contribute to that area, feel free to contact netperf-feedback@netperf.org.

Similarly, if you want tests using the XTI interface, Unix Domain Sockets, DLPI or SCTP it will be necessary to add one or more --enable-[xti|unixdomain|dlpi|sctp]=yes options to the configure command. As of this writing, the configure script will not include those tests automagically.

Starting with version 2.5.0, netperf is migrating most of the “classic” netperf tests found in src/nettest_bsd.c to the so-called “omni” tests (aka “two routines to run them all”) found in src/nettest_omni.c. This migration enables a number of new features such as greater control over what output is included, and new things to output. The “omni” test is enabled by default in 2.5.0 and a number of the classic tests are migrated - you can tell if a test has been migrated from the presence of MIGRATED in the test banner. If you encounter problems with either the omni or migrated tests, please first attempt to obtain resolution via netperf-talk@netperf.org or netperf-feedback@netperf.org. If that is unsuccessful, you can add a --enable-omni=no to the configure command and the omni tests will not be compiled-in and the classic tests will not be migrated.

Starting with version 2.5.0, netperf will include the “burst mode” functionality in a default compilation of the bits. If you encounter problems with this, please first attempt to obtain help via netperf-talk@netperf.org or netperf-feedback@netperf.org. If that is unsuccessful, you can add a --enable-burst=no to the configure command and the burst mode functionality will nt be compiled-in.

On some platforms, it may be necessary to precede the configure command with a CFLAGS and/or LIBS variable as the netperf configure script is not yet smart enough to set them itself. Whenever possible, these requirements will be found in README.platform files. Expertise and assistance in making that more automagical in the configure script would be most welcome.

Other optional configure-time settings include --enable-intervals=yes to give netperf the ability to “pace” its _STREAM tests and --enable-histogram=yes to have netperf keep a histogram of interesting times. Each of these will have some effect on the measured result. If your system supports gethrtime() the effect of the histogram measurement should be minimized but probably still measurable. For example, the histogram of a netperf TCP_RR test will be of the individual transaction times:

     netperf -t TCP_RR -H lag -v 2
     TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to lag.hpl.hp.com (15.4.89.214) port 0 AF_INET : histogram
     Local /Remote
     Socket Size   Request  Resp.   Elapsed  Trans.
     Send   Recv   Size     Size    Time     Rate
     bytes  Bytes  bytes    bytes   secs.    per sec
     
     16384  87380  1        1       10.00    3538.82
     32768  32768
     Alignment      Offset
     Local  Remote  Local  Remote
     Send   Recv    Send   Recv
         8      0       0      0
     Histogram of request/response times
     UNIT_USEC     :    0:    0:    0:    0:    0:    0:    0:    0:    0:    0
     TEN_USEC      :    0:    0:    0:    0:    0:    0:    0:    0:    0:    0
     HUNDRED_USEC  :    0: 34480:  111:   13:   12:    6:    9:    3:    4:    7
     UNIT_MSEC     :    0:   60:   50:   51:   44:   44:   72:  119:  100:  101
     TEN_MSEC      :    0:  105:    0:    0:    0:    0:    0:    0:    0:    0
     HUNDRED_MSEC  :    0:    0:    0:    0:    0:    0:    0:    0:    0:    0
     UNIT_SEC      :    0:    0:    0:    0:    0:    0:    0:    0:    0:    0
     TEN_SEC       :    0:    0:    0:    0:    0:    0:    0:    0:    0:    0
     >100_SECS: 0
     HIST_TOTAL:      35391

The histogram you see above is basically a base-10 log histogram where we can see that most of the transaction times were on the order of one hundred to one-hundred, ninety-nine microseconds, but they were occasionally as long as ten to nineteen milliseconds

The --enable-demo=yes configure option will cause code to be included to report interim results during a test run. The rate at which interim results are reported can then be controlled via the global -D option. Here is an example of -D output:

     $ src/netperf -D 1.35 -H tardy.hpl.hp.com -f M
     MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to tardy.hpl.hp.com (15.9.116.144) port 0 AF_INET : demo
     Interim result:    5.41 MBytes/s over 1.35 seconds ending at 1308789765.848
     Interim result:   11.07 MBytes/s over 1.36 seconds ending at 1308789767.206
     Interim result:   16.00 MBytes/s over 1.36 seconds ending at 1308789768.566
     Interim result:   20.66 MBytes/s over 1.36 seconds ending at 1308789769.922
     Interim result:   22.74 MBytes/s over 1.36 seconds ending at 1308789771.285
     Interim result:   23.07 MBytes/s over 1.36 seconds ending at 1308789772.647
     Interim result:   23.77 MBytes/s over 1.37 seconds ending at 1308789774.016
     Recv   Send    Send
     Socket Socket  Message  Elapsed
     Size   Size    Size     Time     Throughput
     bytes  bytes   bytes    secs.    MBytes/sec
     
      87380  16384  16384    10.06      17.81

Notice how the units of the interim result track that requested by the -f option. Also notice that sometimes the interval will be longer than the value specified in the -D option. This is normal and stems from how demo mode is implemented not by relying on interval timers or frequent calls to get the current time, but by calculating how many units of work must be performed to take at least the desired interval.

Those familiar with this option in earlier versions of netperf will note the addition of the “ending at” text. This is the time as reported by a gettimeofday() call (or its emulation) with a NULL timezone pointer. This addition is intended to make it easier to insert interim results into an rrdtool Round-Robin Database (RRD). A likely bug-riddled example of doing so can be found in doc/examples/netperf_interim_to_rrd.sh. The time is reported out to milliseconds rather than microseconds because that is the most rrdtool understands as of the time of this writing.

As of this writing, a make install will not actually update the files /etc/services and/or /etc/inetd.conf or their platform-specific equivalents. It remains necessary to perform that bit of installation magic by hand. Patches to the makefile sources to effect an automagic editing of the necessary files to have netperf installed as a child of inetd would be most welcome.

Starting the netserver as a standalone daemon should be as easy as:

     $ netserver
     Starting netserver at port 12865
     Starting netserver at hostname 0.0.0.0 port 12865 and family 0

Over time the specifics of the messages netserver prints to the screen may change but the gist will remain the same.

If the compilation of netperf or netserver happens to fail, feel free to contact netperf-feedback@netperf.org or join and ask in netperf-talk@netperf.org. However, it is quite important that you include the actual compilation errors and perhaps even the configure log in your email. Otherwise, it will be that much more difficult for someone to assist you.


Previous: Installing Netperf Bits, Up: Installing Netperf

2.3 Verifying Installation

Basically, once netperf is installed and netserver is configured as a child of inetd, or launched as a standalone daemon, simply typing:

     netperf

should result in output similar to the following:

     $ netperf
     TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost.localdomain (127.0.0.1) port 0 AF_INET
     Recv   Send    Send
     Socket Socket  Message  Elapsed
     Size   Size    Size     Time     Throughput
     bytes  bytes   bytes    secs.    10^6bits/sec
     
      87380  16384  16384    10.00    2997.84


Next: , Previous: Installing Netperf, Up: Top

3 The Design of Netperf

Netperf is designed around a basic client-server model. There are two executables - netperf and netserver. Generally you will only execute the netperf program, with the netserver program being invoked by the remote system's inetd or having been previously started as its own standalone daemon.

When you execute netperf it will establish a “control connection” to the remote system. This connection will be used to pass test configuration information and results to and from the remote system. Regardless of the type of test to be run, the control connection will be a TCP connection using BSD sockets. The control connection can use either IPv4 or IPv6.

Once the control connection is up and the configuration information has been passed, a separate “data” connection will be opened for the measurement itself using the API's and protocols appropriate for the specified test. When the test is completed, the data connection will be torn-down and results from the netserver will be passed-back via the control connection and combined with netperf's result for display to the user.

Netperf places no traffic on the control connection while a test is in progress. Certain TCP options, such as SO_KEEPALIVE, if set as your systems' default, may put packets out on the control connection while a test is in progress. Generally speaking this will have no effect on the results.


Previous: The Design of Netperf, Up: The Design of Netperf

3.1 CPU Utilization

CPU utilization is an important, and alas all-too infrequently reported component of networking performance. Unfortunately, it can be one of the most difficult metrics to measure accurately and portably. Netperf will do its level best to report accurate CPU utilization figures, but some combinations of processor, OS and configuration may make that difficult.

CPU utilization in netperf is reported as a value between 0 and 100% regardless of the number of CPUs involved. In addition to CPU utilization, netperf will report a metric called a service demand. The service demand is the normalization of CPU utilization and work performed. For a _STREAM test it is the microseconds of CPU time consumed to transfer on KB (K == 1024) of data. For a _RR test it is the microseconds of CPU time consumed processing a single transaction. For both CPU utilization and service demand, lower is better.

Service demand can be particularly useful when trying to gauge the effect of a performance change. It is essentially a measure of efficiency, with smaller values being more efficient and thus “better.”

Netperf is coded to be able to use one of several, generally platform-specific CPU utilization measurement mechanisms. Single letter codes will be included in the CPU portion of the test banner to indicate which mechanism was used on each of the local (netperf) and remote (netserver) system.

As of this writing those codes are:

U
The CPU utilization measurement mechanism was unknown to netperf or netperf/netserver was not compiled to include CPU utilization measurements. The code for the null CPU utilization mechanism can be found in src/netcpu_none.c.
I
An HP-UX-specific CPU utilization mechanism whereby the kernel incremented a per-CPU counter by one for each trip through the idle loop. This mechanism was only available on specially-compiled HP-UX kernels prior to HP-UX 10 and is mentioned here only for the sake of historical completeness and perhaps as a suggestion to those who might be altering other operating systems. While rather simple, perhaps even simplistic, this mechanism was quite robust and was not affected by the concerns of statistical methods, or methods attempting to track time in each of user, kernel, interrupt and idle modes which require quite careful accounting. It can be thought-of as the in-kernel version of the looper L mechanism without the context switch overhead. This mechanism required calibration.
P
An HP-UX-specific CPU utilization mechanism whereby the kernel keeps-track of time (in the form of CPU cycles) spent in the kernel idle loop (HP-UX 10.0 to 11.31 inclusive), or where the kernel keeps track of time spent in idle, user, kernel and interrupt processing (HP-UX 11.23 and later). The former requires calibration, the latter does not. Values in either case are retrieved via one of the pstat(2) family of calls, hence the use of the letter P. The code for these mechanisms is found in src/netcpu_pstat.c and src/netcpu_pstatnew.c respectively.
K
A Solaris-specific CPU utilization mechanism whereby the kernel keeps track of ticks (eg HZ) spent in the idle loop. This method is statistical and is known to be inaccurate when the interrupt rate is above epsilon as time spent processing interrupts is not subtracted from idle. The value is retrieved via a kstat() call - hence the use of the letter K. Since this mechanism uses units of ticks (HZ) the calibration value should invariably match HZ. (Eg 100) The code for this mechanism is implemented in src/netcpu_kstat.c.
M
A Solaris-specific mechanism available on Solaris 10 and latter which uses the new microstate accounting mechanisms. There are two, alas, overlapping, mechanisms. The first tracks nanoseconds spent in user, kernel, and idle modes. The second mechanism tracks nanoseconds spent in interrupt. Since the mechanisms overlap, netperf goes through some hand-waving to try to “fix” the problem. Since the accuracy of the handwaving cannot be completely determined, one must presume that while better than the K mechanism, this mechanism too is not without issues. The values are retrieved via kstat() calls, but the letter code is set to M to distinguish this mechanism from the even less accurate K mechanism. The code for this mechanism is implemented in src/netcpu_kstat10.c.
L
A mechanism based on “looper”or “soaker” processes which sit in tight loops counting as fast as they possibly can. This mechanism starts a looper process for each known CPU on the system. The effect of processor hyperthreading on the mechanism is not yet known. This mechanism definitely requires calibration. The code for the “looper”mechanism can be found in src/netcpu_looper.c
N
A Microsoft Windows-specific mechanism, the code for which can be found in src/netcpu_ntperf.c. This mechanism too is based on what appears to be a form of micro-state accounting and requires no calibration. On laptops, or other systems which may dynamically alter the CPU frequency to minimize power consumtion, it has been suggested that this mechanism may become slightly confused, in which case using BIOS/uEFI settings to disable the power saving would be indicated.
S
This mechanism uses /proc/stat on Linux to retrieve time (ticks) spent in idle mode. It is thought but not known to be reasonably accurate. The code for this mechanism can be found in src/netcpu_procstat.c.
C
A mechanism somewhat similar to S but using the sysctl() call on BSD-like Operating systems (*BSD and MacOS X). The code for this mechanism can be found in src/netcpu_sysctl.c.
Others
Other mechanisms included in netperf in the past have included using the times() and getrusage() calls. These calls are actually rather poorly suited to the task of measuring CPU overhead for networking as they tend to be process-specific and much network-related processing can happen outside the context of a process, in places where it is not a given it will be charged to the correct, or even a process. They are mentioned here as a warning to anyone seeing those mechanisms used in other networking benchmarks. These mechanisms are not available in netperf 2.4.0 and later.

For many platforms, the configure script will chose the best available CPU utilization mechanism. However, some platforms have no particularly good mechanisms. On those platforms, it is probably best to use the “LOOPER” mechanism which is basically some number of processes (as many as there are processors) sitting in tight little loops counting as fast as they can. The rate at which the loopers count when the system is believed to be idle is compared with the rate when the system is running netperf and the ratio is used to compute CPU utilization.

In the past, netperf included some mechanisms that only reported CPU time charged to the calling process. Those mechanisms have been removed from netperf versions 2.4.0 and later because they are hopelessly inaccurate. Networking can and often results in CPU time being spent in places - such as interrupt contexts - that do not get charged to a or the correct process.

In fact, time spent in the processing of interrupts is a common issue for many CPU utilization mechanisms. In particular, the “PSTAT” mechanism was eventually known to have problems accounting for certain interrupt time prior to HP-UX 11.11 (11iv1). HP-UX 11iv2 and later are known/presumed to be good. The “KSTAT” mechanism is known to have problems on all versions of Solaris up to and including Solaris 10. Even the microstate accounting available via kstat in Solaris 10 has issues, though perhaps not as bad as those of prior versions.

The /proc/stat mechanism under Linux is in what the author would consider an “uncertain” category as it appears to be statistical, which may also have issues with time spent processing interrupts.

In summary, be sure to “sanity-check” the CPU utilization figures with other mechanisms. However, platform tools such as top, vmstat or mpstat are often based on the same mechanisms used by netperf.


Previous: CPU Utilization, Up: CPU Utilization

3.1.1 CPU Utilization in a Virtual Guest

The CPU utilization mechanisms used by netperf are “inline” in that they are run by the same netperf or netserver process as is running the test itself. This works just fine for “bare iron” tests but runs into a problem when using virtual machines.

The relationship between virtual guest and hypervisor can be thought of as being similar to that between a process and kernel in a bare iron system. As such, (m)any CPU utilization mechanisms used in the virtual guest are similar to “process-local” mechanisms in a bare iron situation. However, just as with bare iron and process-local mechanisms, much networking processing happens outside the context of the virtual guest. It takes place in the hypervisor, and is not visible to mechanisms running in the guest(s). For this reason, one should not really trust CPU utilization figures reported by netperf or netserver when running in a virtual guest.

If one is looking to measure the added overhead of a virtualization mechanism, rather than rely on CPU utilization, one can rely instead on netperf _RR tests - path-lengths and overheads can be a significant fraction of the latency, so increases in overhead should appear as decreases in transaction rate. Whatever you do, DO NOT rely on the throughput of a _STREAM test. Achieving link-rate can be done via a multitude of options that mask overhead rather than eliminate it.


Next: , Previous: The Design of Netperf, Up: Top

4 Global Command-line Options

This section describes each of the global command-line options available in the netperf and netserver binaries. Essentially, it is an expanded version of the usage information displayed by netperf or netserver when invoked with the -h global command-line option.


Next: , Previous: Global Command-line Options, Up: Global Command-line Options

4.1 Command-line Options Syntax

Revision 1.8 of netperf introduced enough new functionality to overrun the English alphabet for mnemonic command-line option names, and the author was not and is not quite ready to switch to the contemporary --mumble style of command-line options. (Call him a Luddite if you wish :).

For this reason, the command-line options were split into two parts - the first are the global command-line options. They are options that affect nearly any and every test type of netperf. The second type are the test-specific command-line options. Both are entered on the same command line, but they must be separated from one another by a -- for correct parsing. Global command-line options come first, followed by the -- and then test-specific command-line options. If there are no test-specific options to be set, the -- may be omitted. If there are no global command-line options to be set, test-specific options must still be preceded by a --. For example:

     netperf <global> -- <test-specific>

sets both global and test-specific options:

     netperf <global>

sets just global options and:

     netperf -- <test-specific>

sets just test-specific options.


Previous: Command-line Options Syntax, Up: Global Command-line Options

4.2 Global Options

-a <sizespec>
This option allows you to alter the alignment of the buffers used in the sending and receiving calls on the local system.. Changing the alignment of the buffers can force the system to use different copy schemes, which can have a measurable effect on performance. If the page size for the system were 4096 bytes, and you want to pass page-aligned buffers beginning on page boundaries, you could use ‘-a 4096’. By default the units are bytes, but suffix of “G,” “M,” or “K” will specify the units to be 2^30 (GB), 2^20 (MB) or 2^10 (KB) respectively. A suffix of “g,” “m” or “k” will specify units of 10^9, 10^6 or 10^3 bytes respectively. [Default: 8 bytes]


-A <sizespec>
This option is identical to the -a option with the difference being it affects alignments for the remote system.


-b <size>
This option is only present when netperf has been configure with –enable-intervals=yes prior to compilation. It sets the size of the burst of send calls in a _STREAM test. When used in conjunction with the -w option it can cause the rate at which data is sent to be “paced.”


-B <string>
This option will cause <string> to be appended to the brief (see -P) output of netperf.


-c [rate]
This option will ask that CPU utilization and service demand be calculated for the local system. For those CPU utilization mechanisms requiring calibration, the options rate parameter may be specified to preclude running another calibration step, saving 40 seconds of time. For those CPU utilization mechanisms requiring no calibration, the optional rate parameter will be utterly and completely ignored. [Default: no CPU measurements]


-C [rate]
This option requests CPU utilization and service demand calculations for the remote system. It is otherwise identical to the -c option.


-d
Each instance of this option will increase the quantity of debugging output displayed during a test. If the debugging output level is set high enough, it may have a measurable effect on performance. Debugging information for the local system is printed to stdout. Debugging information for the remote system is sent by default to the file /tmp/netperf.debug. [Default: no debugging output]


-D [interval,units]
This option is only available when netperf is configured with –enable-demo=yes. When set, it will cause netperf to emit periodic reports of performance during the run. [interval,units] follow the semantics of an optionspec. If specified, interval gives the minimum interval in real seconds, it does not have to be whole seconds. The units value can be used for the first guess as to how many units of work (bytes or transactions) must be done to take at least interval seconds. If omitted, interval defaults to one second and units to values specific to each test type.


-f G|M|K|g|m|k|x
This option can be used to change the reporting units for _STREAM tests. Arguments of “G,” “M,” or “K” will set the units to 2^30, 2^20 or 2^10 bytes/s respectively (EG power of two GB, MB or KB). Arguments of “g,” “,m” or “k” will set the units to 10^9, 10^6 or 10^3 bits/s respectively. An argument of “x” requests the units be transactions per second and is only meaninful for a request-response test. [Default: “m” or 10^6 bits/s]


-F <fillfile>
This option specified the file from which send which buffers will be pre-filled . While the buffers will contain data from the specified file, the file is not fully transfered to the remote system as the receiving end of the test will not write the contents of what it receives to a file. This can be used to pre-fill the send buffers with data having different compressibility and so is useful when measuring performance over mechanisms which perform compression.

While previously required for a TCP_SENDFILE test, later versions of netperf removed that restriction, creating a temporary file as needed. While the author cannot recall exactly when that took place, it is known to be unnecessary in version 2.5.0 and later.


-h
This option causes netperf to display its “global” usage string and exit to the exclusion of all else.


-H <optionspec>
This option will set the name of the remote system and or the address family used for the control connection. For example:
          -H linger,4

will set the name of the remote system to “linger” and tells netperf to use IPv4 addressing only.

          -H ,6

will leave the name of the remote system at its default, and request that only IPv6 addresses be used for the control connection.

          -H lag

will set the name of the remote system to “lag” and leave the address family to AF_UNSPEC which means selection of IPv4 vs IPv6 is left to the system's address resolution.

A value of “inet” can be used in place of “4” to request IPv4 only addressing. Similarly, a value of “inet6” can be used in place of “6” to request IPv6 only addressing. A value of “0” can be used to request either IPv4 or IPv6 addressing as name resolution dictates.

By default, the options set with the global -H option are inherited by the test for its data connection, unless a test-specific -H option is specified.

If a -H option follows either the -4 or -6 options, the family setting specified with the -H option will override the -4 or -6 options for the remote address family. If no address family is specified, settings from a previous -4 or -6 option will remain. In a nutshell, the last explicit global command-line option wins.

[Default: “localhost” for the remote name/IP address and “0” (eg AF_UNSPEC) for the remote address family.]


-I <optionspec>
This option enables the calculation of confidence intervals and sets the confidence and width parameters with the first half of the optionspec being either 99 or 95 for 99% or 95% confidence respectively. The second value of the optionspec specifies the width of the desired confidence interval. For example
          -I 99,5

asks netperf to be 99% confident that the measured mean values for throughput and CPU utilization are within +/- 2.5% of the “real” mean values. If the -i option is specified and the -I option is omitted, the confidence defaults to 99% and the width to 5% (giving +/- 2.5%)

If classic netperf test calculates that the desired confidence intervals have not been met, it emits a noticeable warning that cannot be suppressed with the -P or -v options:

          netperf -H tardy.cup -i 3 -I 99,5
          TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to tardy.cup.hp.com (15.244.44.58) port 0 AF_INET : +/-2.5%  99% conf.
          !!! WARNING
          !!! Desired confidence was not achieved within the specified iterations.
          !!! This implies that there was variability in the test environment that
          !!! must be investigated before going further.
          !!! Confidence intervals: Throughput      :  6.8%
          !!!                       Local CPU util  :  0.0%
          !!!                       Remote CPU util :  0.0%
          
          Recv   Send    Send
          Socket Socket  Message  Elapsed
          Size   Size    Size     Time     Throughput
          bytes  bytes   bytes    secs.    10^6bits/sec
          
           32768  16384  16384    10.01      40.23

In the example above we see that netperf did not meet the desired convidence intervals. Instead of being 99% confident it was within +/- 2.5% of the real mean value of throughput it is only confident it was within +/-3.4%. In this example, increasing the -i option (described below) and/or increasing the iteration length with the -l option might resolve the situation.

In an explicit “omni” test, failure to meet the confidence intervals will not result in netperf emitting a warning. To verify the hitting, or not, of the confidence intervals one will need to include them as part of an an output selection in the test-specific -o, -O or k output selection options. The warning about not hitting the confidence intervals will remain in a “migrated” classic netperf test.


-i <sizespec>
This option enables the calculation of confidence intervals and sets the minimum and maximum number of iterations to run in attempting to achieve the desired confidence interval. The first value sets the maximum number of iterations to run, the second, the minimum. The maximum number of iterations is silently capped at 30 and the minimum is silently floored at 3. Netperf repeats the measurement the minimum number of iterations and continues until it reaches either the desired confidence interval, or the maximum number of iterations, whichever comes first. A classic or migrated netperf test will not display the actual number of iterations run. An omni test will emit the number of iterations run if the CONFIDENCE_ITERATION output selector is included in the output selection.

If the -I option is specified and the -i option omitted the maximum number of iterations is set to 10 and the minimum to three.

Output of a warning upon not hitting the desired confidence intervals follows the description provided for the -I option.

The total test time will be somewhere between the minimum and maximum number of iterations multiplied by the test length supplied by the -l option.


-j
This option instructs netperf to keep additional timing statistics when explicitly running an omni test. These can be output when the test-specific -o, -O or -k output selectors include one or more of:

These statistics will be based on an expanded (100 buckets per row rather than 10) histogram of times rather than a terribly long list of individual times. As such, there will be some slight error thanks to the bucketing. However, the reduction in storage and processing overheads is well worth it. When running a request/response test, one might get some idea of the error by comparing the MEAN_LATENCY calculated from the histogram with the RT_LATENCY calculated from the number of request/response transactions and the test run time.

In the case of a request/response test the latencies will be transaction latencies. In the case of a receive-only test they will be time spent in the receive call. In the case of a send-only test they will be tim spent in the send call. The units will be microseconds. Added in netperf 2.5.0.


-l testlen
This option controls the length of any one iteration of the requested test. A positive value for testlen will run each iteration of the test for at least testlen seconds. A negative value for testlen will run each iteration for the absolute value of testlen transactions for a _RR test or bytes for a _STREAM test. Certain tests, notably those using UDP can only be timed, they cannot be limited by transaction or byte count. This limitation may be relaxed in an omni test.

In some situations, individual iterations of a test may run for longer for the number of seconds specified by the -l option. In particular, this may occur for those tests where the socket buffer size(s) are significantly longer than the bandwidthXdelay product of the link(s) over which the data connection passes, or those tests where there may be non-trivial numbers of retransmissions.

If confidence intervals are enabled via either -I or -i the total length of the netperf test will be somewhere between the minimum and maximum iteration count multiplied by testlen.


-L <optionspec>
This option is identical to the -H option with the difference being it sets the _local_ hostname/IP and/or address family information. This option is generally unnecessary, but can be useful when you wish to make sure that the netperf control and data connections go via different paths. It can also come-in handy if one is trying to run netperf through those evil, end-to-end breaking things known as firewalls.

[Default: 0.0.0.0 (eg INADDR_ANY) for IPv4 and ::0 for IPv6 for the local name. AF_UNSPEC for the local address family.]


-n numcpus
This option tells netperf how many CPUs it should ass-u-me are active on the system running netperf. In particular, this is used for the CPU utilization and service demand calculations. On certain systems, netperf is able to determine the number of CPU's automagically. This option will override any number netperf might be able to determine on its own.

Note that this option does _not_ set the number of CPUs on the system running netserver. When netperf/netserver cannot automagically determine the number of CPUs that can only be set for netserver via a netserver -n command-line option.

As it is almost universally possible for netperf/netserver to determine the number of CPUs on the system automagically, 99 times out of 10 this option should not be necessary and may be removed in a future release of netperf.


-N
This option tells netperf to forego establishing a control connection. This makes it is possible to run some limited netperf tests without a corresponding netserver on the remote system.

With this option set, the test to be run is to get all the addressing information it needs to establish its data connection from the command line or internal defaults. If not otherwise specified by test-specific command line options, the data connection for a “STREAM” or “SENDFILE” test will be to the “discard” port, an “RR” test will be to the “echo” port, and a “MEARTS” test will be to the chargen port.

The response size of an “RR” test will be silently set to be the same as the request size. Otherwise the test would hang if the response size was larger than the request size, or would report an incorrect, inflated transaction rate if the response size was less than the request size.

Since there is no control connection when this option is specified, it is not possible to set “remote” properties such as socket buffer size and the like via the netperf command line. Nor is it possible to retrieve such interesting remote information as CPU utilization. These items will be displayed as values which should make it immediately obvious that was the case.

The only way to change remote characteristics such as socket buffer size or to obtain information such as CPU utilization is to employ platform-specific methods on the remote system. Frankly, if one has access to the remote system to employ those methods one aught to be able to run a netserver there. However, that ability may not be present in certain “support” situations, hence the addition of this option.

Added in netperf 2.4.3.


-o <sizespec>
The value(s) passed-in with this option will be used as an offset added to the alignment specified with the -a option. For example:
          -o 3 -a 4096

will cause the buffers passed to the local (netperf) send and receive calls to begin three bytes past an address aligned to 4096 bytes. [Default: 0 bytes]


-O <sizespec>
This option behaves just as the -o option but on the remote (netserver) system and in conjunction with the -A option. [Default: 0 bytes]


-p <optionspec>
The first value of the optionspec passed-in with this option tells netperf the port number at which it should expect the remote netserver to be listening for control connections. The second value of the optionspec will request netperf to bind to that local port number before establishing the control connection. For example
          -p 12345

tells netperf that the remote netserver is listening on port 12345 and leaves selection of the local port number for the control connection up to the local TCP/IP stack whereas

          -p ,32109

leaves the remote netserver port at the default value of 12865 and causes netperf to bind to the local port number 32109 before connecting to the remote netserver.

In general, setting the local port number is only necessary when one is looking to run netperf through those evil, end-to-end breaking things known as firewalls.


-P 0|1
A value of “1” for the -P option will enable display of the test banner. A value of “0” will disable display of the test banner. One might want to disable display of the test banner when running the same basic test type (eg TCP_STREAM) multiple times in succession where the test banners would then simply be redundant and unnecessarily clutter the output. [Default: 1 - display test banners]


-s <seconds>
This option will cause netperf to sleep ‘<seconds>’ before actually transferring data over the data connection. This may be useful in situations where one wishes to start a great many netperf instances and do not want the earlier ones affecting the ability of the later ones to get established.

Added somewhere between versions 2.4.3 and 2.5.0.


-S
This option will cause an attempt to be made to set SO_KEEPALIVE on the data socket of a test using the BSD sockets interface. The attempt will be made on the netperf side of all tests, and will be made on the netserver side of an omni or migrated test. No indication of failure is given unless debug output is enabled with the global -d option.

Added in version 2.5.0.


-t testname
This option is used to tell netperf which test you wish to run. As of this writing, valid values for testname include: Not all tests are always compiled into netperf. In particular, the “XTI,” “SCTP,” “UNIXDOMAIN,” and “DL*” tests are only included in netperf when configured with --enable-[xti|sctp|unixdomain|dlpi]=yes.

Netperf only runs one type of test no matter how many -t options may be present on the command-line. The last -t global command-line option will determine the test to be run. [Default: TCP_STREAM]


-T <optionspec>
This option controls the CPU, and probably by extension memory, affinity of netperf and/or netserver.
          netperf -T 1

will bind both netperf and netserver to “CPU 1” on their respective systems.

          netperf -T 1,

will bind just netperf to “CPU 1” and will leave netserver unbound.

          netperf -T ,2

will leave netperf unbound and will bind netserver to “CPU 2.”

          netperf -T 1,2

will bind netperf to “CPU 1” and netserver to “CPU 2.”

This can be particularly useful when investigating performance issues involving where processes run relative to where NIC interrupts are processed or where NICs allocate their DMA buffers.


-v verbosity
This option controls how verbose netperf will be in its output, and is often used in conjunction with the -P option. If the verbosity is set to a value of “0” then only the test's SFM (Single Figure of Merit) is displayed. If local CPU utilization is requested via the -c option then the SFM is the local service demand. Othersise, if remote CPU utilization is requested via the -C option then the SFM is the remote service demand. If neither local nor remote CPU utilization are requested the SFM will be the measured throughput or transaction rate as implied by the test specified with the -t option.

If the verbosity level is set to “1” then the “normal” netperf result output for each test is displayed.

If the verbosity level is set to “2” then “extra” information will be displayed. This may include, but is not limited to the number of send or recv calls made and the average number of bytes per send or recv call, or a histogram of the time spent in each send() call or for each transaction if netperf was configured with --enable-histogram=yes. [Default: 1 - normal verbosity]

In an omni test the verbosity setting is largely ignored, save for when asking for the time histogram to be displayed. In version 2.5.0 there is no output selector for the histogram and so it remains displayed only when the verbosity level is set to 2.


-V
This option displays the netperf version and then exits.

Added in netperf 2.4.4.


-w time
If netperf was configured with --enable-intervals=yes then this value will set the inter-burst time to time milliseconds, and the -b option will set the number of sends per burst. The actual inter-burst time may vary depending on the system's timer resolution.


-W <sizespec>
This option controls the number of buffers in the send (first or only value) and or receive (second or only value) buffer rings. Unlike some benchmarks, netperf does not continuously send or receive from a single buffer. Instead it rotates through a ring of buffers. [Default: One more than the size of the send or receive socket buffer sizes (-s and/or -S options) divided by the send -m or receive -M buffer size respectively]


-4
Specifying this option will set both the local and remote address families to AF_INET - that is use only IPv4 addresses on the control connection. This can be overridden by a subsequent -6, -H or -L option. Basically, the last option explicitly specifying an address family wins. Unless overridden by a test-specific option, this will be inherited for the data connection as well.


-6
Specifying this option will set both local and and remote address families to AF_INET6 - that is use only IPv6 addresses on the control connection. This can be overridden by a subsequent -4, -H or -L option. Basically, the last address family explicitly specified wins. Unless overridden by a test-specific option, this will be inherited for the data connection as well.


Next: , Previous: Global Command-line Options, Up: Top

5 Using Netperf to Measure Bulk Data Transfer

The most commonly measured aspect of networked system performance is that of bulk or unidirectional transfer performance. Everyone wants to know how many bits or bytes per second they can push across the network. The classic netperf convention for a bulk data transfer test name is to tack a “_STREAM” suffix to a test name.


Next: , Previous: Using Netperf to Measure Bulk Data Transfer, Up: Using Netperf to Measure Bulk Data Transfer

5.1 Issues in Bulk Transfer

There are any number of things which can affect the performance of a bulk transfer test.

Certainly, absent compression, bulk-transfer tests can be limited by the speed of the slowest link in the path from the source to the destination. If testing over a gigabit link, you will not see more than a gigabit :) Such situations can be described as being network-limited or NIC-limited.

CPU utilization can also affect the results of a bulk-transfer test. If the networking stack requires a certain number of instructions or CPU cycles per KB of data transferred, and the CPU is limited in the number of instructions or cycles it can provide, then the transfer can be described as being CPU-bound.

A bulk-transfer test can be CPU bound even when netperf reports less than 100% CPU utilization. This can happen on an MP system where one or more of the CPUs saturate at 100% but other CPU's remain idle. Typically, a single flow of data, such as that from a single instance of a netperf _STREAM test cannot make use of much more than the power of one CPU. Exceptions to this generally occur when netperf and/or netserver run on CPU(s) other than the CPU(s) taking interrupts from the NIC(s). In that case, one might see as much as two CPUs' worth of processing being used to service the flow of data.

Distance and the speed-of-light can affect performance for a bulk-transfer; often this can be mitigated by using larger windows. One common limit to the performance of a transport using window-based flow-control is:

     Throughput <= WindowSize/RoundTripTime

As the sender can only have a window's-worth of data outstanding on the network at any one time, and the soonest the sender can receive a window update from the receiver is one RoundTripTime (RTT). TCP and SCTP are examples of such protocols.

Packet losses and their effects can be particularly bad for performance. This is especially true if the packet losses result in retransmission timeouts for the protocol(s) involved. By the time a retransmission timeout has happened, the flow or connection has sat idle for a considerable length of time.

On many platforms, some variant on the netstat command can be used to retrieve statistics about packet loss and retransmission. For example:

     netstat -p tcp

will retrieve TCP statistics on the HP-UX Operating System. On other platforms, it may not be possible to retrieve statistics for a specific protocol and something like:

     netstat -s

would be used instead.

Many times, such network statistics are keep since the time the stack started, and we are only really interested in statistics from when netperf was running. In such situations something along the lines of:

     netstat -p tcp > before
     netperf -t TCP_mumble...
     netstat -p tcp > after

is indicated. The beforeafter utility can be used to subtract the statistics in before from the statistics in after:

     beforeafter before after > delta

and then one can look at the statistics in delta. Beforeafter is distributed in source form so one can compile it on the platform(s) of interest.

If running a version 2.5.0 or later “omni” test under Linux one can include either or both of:

in the values provided via a test-specific -o, -O, or -k output selction option and netperf will report the retransmissions experienced on the data connection, as reported via a getsockopt(TCP_INFO) call. If confidence intervals have been requested via the global -I or -i options, the reported value(s) will be for the last iteration. If the test is over a protocol other than TCP, or on a platform other than Linux, the results are undefined.

While it was written with HP-UX's netstat in mind, the annotated netstat writeup may be helpful with other platforms as well.


Previous: Issues in Bulk Transfer, Up: Using Netperf to Measure Bulk Data Transfer

5.2 Options common to TCP UDP and SCTP tests

Many “test-specific” options are actually common across the different tests. For those tests involving TCP, UDP and SCTP, whether using the BSD Sockets or the XTI interface those common options include:

-h
Display the test-suite-specific usage string and exit. For a TCP_ or UDP_ test this will be the usage string from the source file nettest_bsd.c. For an XTI_ test, this will be the usage string from the source file nettest_xti.c. For an SCTP test, this will be the usage string from the source file nettest_sctp.c.
-H <optionspec>
Normally, the remote hostname|IP and address family information is inherited from the settings for the control connection (eg global command-line -H, -4 and/or -6 options). The test-specific -H will override those settings for the data (aka test) connection only. Settings for the control connection are left unchanged.


-L <optionspec>
The test-specific -L option is identical to the test-specific -H option except it affects the local hostname|IP and address family information. As with its global command-line counterpart, this is generally only useful when measuring though those evil, end-to-end breaking things called firewalls.


-m bytes
Set the size of the buffer passed-in to the “send” calls of a _STREAM test. Note that this may have only an indirect effect on the size of the packets sent over the network, and certain Layer 4 protocols do _not_ preserve or enforce message boundaries, so setting -m for the send size does not necessarily mean the receiver will receive that many bytes at any one time. By default the units are bytes, but suffix of “G,” “M,” or “K” will specify the units to be 2^30 (GB), 2^20 (MB) or 2^10 (KB) respectively. A suffix of “g,” “m” or “k” will specify units of 10^9, 10^6 or 10^3 bytes respectively. For example:
          -m 32K

will set the size to 32KB or 32768 bytes. [Default: the local send socket buffer size for the connection - either the system's default or the value set via the -s option.]


-M bytes
Set the size of the buffer passed-in to the “recv” calls of a _STREAM test. This will be an upper bound on the number of bytes received per receive call. By default the units are bytes, but suffix of “G,” “M,” or “K” will specify the units to be 2^30 (GB), 2^20 (MB) or 2^10 (KB) respectively. A suffix of “g,” “m” or “k” will specify units of 10^9, 10^6 or 10^3 bytes respectively. For example:
          -M 32K

will set the size to 32KB or 32768 bytes. [Default: the remote receive socket buffer size for the data connection - either the system's default or the value set via the -S option.]


-P <optionspec>
Set the local and/or remote port numbers for the data connection.


-s <sizespec>
This option sets the local (netperf) send and receive socket buffer sizes for the data connection to the value(s) specified. Often, this will affect the advertised and/or effective TCP or other window, but on some platforms it may not. By default the units are bytes, but suffix of “G,” “M,” or “K” will specify the units to be 2^30 (GB), 2^20 (MB) or 2^10 (KB) respectively. A suffix of “g,” “m” or “k” will specify units of 10^9, 10^6 or 10^3 bytes respectively. For example:
          -s 128K

Will request the local send and receive socket buffer sizes to be 128KB or 131072 bytes.

While the historic expectation is that setting the socket buffer size has a direct effect on say the TCP window, today that may not hold true for all stacks. Further, while the historic expectation is that the value specified in a setsockopt() call will be the value returned via a getsockopt() call, at least one stack is known to deliberately ignore history. When running under Windows a value of 0 may be used which will be an indication to the stack the user wants to enable a form of copy avoidance. [Default: -1 - use the system's default socket buffer sizes]


-S <sizespec>
This option sets the remote (netserver) send and/or receive socket buffer sizes for the data connection to the value(s) specified. Often, this will affect the advertised and/or effective TCP or other window, but on some platforms it may not. By default the units are bytes, but suffix of “G,” “M,” or “K” will specify the units to be 2^30 (GB), 2^20 (MB) or 2^10 (KB) respectively. A suffix of “g,” “m” or “k” will specify units of 10^9, 10^6 or 10^3 bytes respectively. For example:
          -s 128K

Will request the remote send and receive socket buffer sizes to be 128KB or 131072 bytes.

While the historic expectation is that setting the socket buffer size has a direct effect on say the TCP window, today that may not hold true for all stacks. Further, while the historic expectation is that the value specified in a setsockopt() call will be the value returned via a getsockopt() call, at least one stack is known to deliberately ignore history. When running under Windows a value of 0 may be used which will be an indication to the stack the user wants to enable a form of copy avoidance. [Default: -1 - use the system's default socket buffer sizes]


-4
Set the local and remote address family for the data connection to AF_INET - ie use IPv4 addressing only. Just as with their global command-line counterparts the last of the -4, -6, -H or -L option wins for their respective address families.


-6
This option is identical to its -4 cousin, but requests IPv6 addresses for the local and remote ends of the data connection.


Next: , Previous: Options common to TCP UDP and SCTP tests, Up: Options common to TCP UDP and SCTP tests

5.2.1 TCP_STREAM

The TCP_STREAM test is the default test in netperf. It is quite simple, transferring some quantity of data from the system running netperf to the system running netserver. While time spent establishing the connection is not included in the throughput calculation, time spent flushing the last of the data to the remote at the end of the test is. This is how netperf knows that all the data it sent was received by the remote. In addition to the options common to STREAM tests, the following test-specific options can be included to possibly alter the behavior of the test:

-C
This option will set TCP_CORK mode on the data connection on those systems where TCP_CORK is defined (typically Linux). A full description of TCP_CORK is beyond the scope of this manual, but in a nutshell it forces sub-MSS sends to be buffered so every segment sent is Maximum Segment Size (MSS) unless the application performs an explicit flush operation or the connection is closed. At present netperf does not perform any explicit flush operations. Setting TCP_CORK may improve the bitrate of tests where the “send size” (-m option) is smaller than the MSS. It should also improve (make smaller) the service demand.

The Linux tcp(7) manpage states that TCP_CORK cannot be used in conjunction with TCP_NODELAY (set via the -d option), however netperf does not validate command-line options to enforce that.

-D
This option will set TCP_NODELAY on the data connection on those systems where TCP_NODELAY is defined. This disables something known as the Nagle Algorithm, which is intended to make the segments TCP sends as large as reasonably possible. Setting TCP_NODELAY for a TCP_STREAM test should either have no effect when the send size (-m option) is larger than the MSS or will decrease reported bitrate and increase service demand when the send size is smaller than the MSS. This stems from TCP_NODELAY causing each sub-MSS send to be its own TCP segment rather than being aggregated with other small sends. This means more trips up and down the protocol stack per KB of data transferred, which means greater CPU utilization.

If setting TCP_NODELAY with -D affects throughput and/or service demand for tests where the send size (-m) is larger than the MSS it suggests the TCP/IP stack's implementation of the Nagle Algorithm _may_ be broken, perhaps interpreting the Nagle Algorithm on a segment by segment basis rather than the proper user send by user send basis. However, a better test of this can be achieved with the TCP_RR test.

Here is an example of a basic TCP_STREAM test, in this case from a Debian Linux (2.6 kernel) system to an HP-UX 11iv2 (HP-UX 11.23) system:

     $ netperf -H lag
     TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to lag.hpl.hp.com (15.4.89.214) port 0 AF_INET
     Recv   Send    Send
     Socket Socket  Message  Elapsed
     Size   Size    Size     Time     Throughput
     bytes  bytes   bytes    secs.    10^6bits/sec
     
      32768  16384  16384    10.00      80.42

We see that the default receive socket buffer size for the receiver (lag - HP-UX 11.23) is 32768 bytes, and the default socket send buffer size for the sender (Debian 2.6 kernel) is 16384 bytes, however Linux does “auto tuning” of socket buffer and TCP window sizes, which means the send socket buffer size may be different at the end of the test than it was at the beginning. This is addressed in the omni tests added in version 2.5.0 and output selection. Througput is expressed as 10^6 (aka Mega) bits per second, and the test ran for 10 seconds. IPv4 addresses (AF_INET) were used.


Next: , Previous: TCP_STREAM, Up: Options common to TCP UDP and SCTP tests

5.2.2 TCP_MAERTS

A TCP_MAERTS (MAERTS is STREAM backwards) test is “just like” a TCP_STREAM test except the data flows from the netserver to the netperf. The global command-line -F option is ignored for this test type. The test-specific command-line -C option is ignored for this test type.

Here is an example of a TCP_MAERTS test between the same two systems as in the example for the TCP_STREAM test. This time we request larger socket buffers with -s and -S options:

     $ netperf -H lag -t TCP_MAERTS -- -s 128K -S 128K
     TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to lag.hpl.hp.com (15.4.89.214) port 0 AF_INET
     Recv   Send    Send
     Socket Socket  Message  Elapsed
     Size   Size    Size     Time     Throughput
     bytes  bytes   bytes    secs.    10^6bits/sec
     
     221184 131072 131072    10.03      81.14

Where we see that Linux, unlike HP-UX, may not return the same value in a getsockopt() as was requested in the prior setsockopt().

This test is included more for benchmarking convenience than anything else.


Next: , Previous: TCP_MAERTS, Up: Options common to TCP UDP and SCTP tests

5.2.3 TCP_SENDFILE

The TCP_SENDFILE test is “just like” a TCP_STREAM test except netperf the platform's sendfile() call instead of calling send(). Often this results in a zero-copy operation where data is sent directly from the filesystem buffer cache. This _should_ result in lower CPU utilization and possibly higher throughput. If it does not, then you may want to contact your vendor(s) because they have a problem on their hands.

Zero-copy mechanisms may also alter the characteristics (size and number of buffers per) of packets passed to the NIC. In many stacks, when a copy is performed, the stack can “reserve” space at the beginning of the destination buffer for things like TCP, IP and Link headers. This then has the packet contained in a single buffer which can be easier to DMA to the NIC. When no copy is performed, there is no opportunity to reserve space for headers and so a packet will be contained in two or more buffers.

As of some time before version 2.5.0, the global -F option is no longer required for this test. If it is not specified, netperf will create a temporary file, which it will delete at the end of the test. If the -F option is specified it must reference a file of at least the size of the send ring (See the global -W option.) multiplied by the send size (See the test-specific -m option.). All other TCP-specific options remain available and optional.

In this first example:

     $ netperf -H lag -F ../src/netperf -t TCP_SENDFILE -- -s 128K -S 128K
     TCP SENDFILE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to lag.hpl.hp.com (15.4.89.214) port 0 AF_INET
     alloc_sendfile_buf_ring: specified file too small.
     file must be larger than send_width * send_size

we see what happens when the file is too small. Here:

     $ netperf -H lag -F /boot/vmlinuz-2.6.8-1-686 -t TCP_SENDFILE -- -s 128K -S 128K
     TCP SENDFILE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to lag.hpl.hp.com (15.4.89.214) port 0 AF_INET
     Recv   Send    Send
     Socket Socket  Message  Elapsed
     Size   Size    Size     Time     Throughput
     bytes  bytes   bytes    secs.    10^6bits/sec
     
     131072 221184 221184    10.02      81.83

we resolve that issue by selecting a larger file.


Next: , Previous: TCP_SENDFILE, Up: Options common to TCP UDP and SCTP tests

5.2.4 UDP_STREAM

A UDP_STREAM test is similar to a TCP_STREAM test except UDP is used as the transport rather than TCP.

A UDP_STREAM test has no end-to-end flow control - UDP provides none and neither does netperf. However, if you wish, you can configure netperf with --enable-intervals=yes to enable the global command-line -b and -w options to pace bursts of traffic onto the network.

This has a number of implications.

The biggest of these implications is the data which is sent might not be received by the remote. For this reason, the output of a UDP_STREAM test shows both the sending and receiving throughput. On some platforms, it may be possible for the sending throughput to be reported as a value greater than the maximum rate of the link. This is common when the CPU(s) are faster than the network and there is no intra-stack flow-control.

Here is an example of a UDP_STREAM test between two systems connected by a 10 Gigabit Ethernet link:

     $ netperf -t UDP_STREAM -H 192.168.2.125 -- -m 32768
     UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.2.125 (192.168.2.125) port 0 AF_INET
     Socket  Message  Elapsed      Messages
     Size    Size     Time         Okay Errors   Throughput
     bytes   bytes    secs            #      #   10^6bits/sec
     
     124928   32768   10.00      105672      0    2770.20
     135168           10.00      104844           2748.50
     

The first line of numbers are statistics from the sending (netperf) side. The second line of numbers are from the receiving (netserver) side. In this case, 105672 - 104844 or 828 messages did not make it all the way to the remote netserver process.

If the value of the -m option is larger than the local send socket buffer size (-s option) netperf will likely abort with an error message about how the send call failed:

     netperf -t UDP_STREAM -H 192.168.2.125
     UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.2.125 (192.168.2.125) port 0 AF_INET
     udp_send: data send error: Message too long

If the value of the -m option is larger than the remote socket receive buffer, the reported receive throughput will likely be zero as the remote UDP will discard the messages as being too large to fit into the socket buffer.

     $ netperf -t UDP_STREAM -H 192.168.2.125 -- -m 65000 -S 32768
     UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.2.125 (192.168.2.125) port 0 AF_INET
     Socket  Message  Elapsed      Messages
     Size    Size     Time         Okay Errors   Throughput
     bytes   bytes    secs            #      #   10^6bits/sec
     
     124928   65000   10.00       53595      0    2786.99
      65536           10.00           0              0.00

The example above was between a pair of systems running a “Linux” kernel. Notice that the remote Linux system returned a value larger than that passed-in to the -S option. In fact, this value was larger than the message size set with the -m option. That the remote socket buffer size is reported as 65536 bytes would suggest to any sane person that a message of 65000 bytes would fit, but the socket isn't _really_ 65536 bytes, even though Linux is telling us so. Go figure.


Next: , Previous: UDP_STREAM, Up: Options common to TCP UDP and SCTP tests

5.2.5 XTI_TCP_STREAM

An XTI_TCP_STREAM test is simply a TCP_STREAM test using the XTI rather than BSD Sockets interface. The test-specific -X <devspec> option can be used to specify the name of the local and/or remote XTI device files, which is required by the t_open() call made by netperf XTI tests.

The XTI_TCP_STREAM test is only present if netperf was configured with --enable-xti=yes. The remote netserver must have also been configured with --enable-xti=yes.


Next: , Previous: XTI_TCP_STREAM, Up: Options common to TCP UDP and SCTP tests

5.2.6 XTI_UDP_STREAM

An XTI_UDP_STREAM test is simply a UDP_STREAM test using the XTI rather than BSD Sockets Interface. The test-specific -X <devspec> option can be used to specify the name of the local and/or remote XTI device files, which is required by the t_open() call made by netperf XTI tests.

The XTI_UDP_STREAM test is only present if netperf was configured with --enable-xti=yes. The remote netserver must have also been configured with --enable-xti=yes.


Next: , Previous: XTI_UDP_STREAM, Up: Options common to TCP UDP and SCTP tests

5.2.7 SCTP_STREAM

An SCTP_STREAM test is essentially a TCP_STREAM test using the SCTP rather than TCP. The -D option will set SCTP_NODELAY, which is much like the TCP_NODELAY option for TCP. The -C option is not applicable to an SCTP test as there is no corresponding SCTP_CORK option. The author is still figuring-out what the test-specific -N option does :)

The SCTP_STREAM test is only present if netperf was configured with --enable-sctp=yes. The remote netserver must have also been configured with --enable-sctp=yes.


Next: , Previous: SCTP_STREAM, Up: Options common to TCP UDP and SCTP tests

5.2.8 DLCO_STREAM

A DLPI Connection Oriented Stream (DLCO_STREAM) test is very similar in concept to a TCP_STREAM test. Both use reliable, connection-oriented protocols. The DLPI test differs from the TCP test in that its protocol operates only at the link-level and does not include TCP-style segmentation and reassembly. This last difference means that the value passed-in with the -m option must be less than the interface MTU. Otherwise, the -m and -M options are just like their TCP/UDP/SCTP counterparts.

Other DLPI-specific options include:

-D <devspec>
This option is used to provide the fully-qualified names for the local and/or remote DPLI device files. The syntax is otherwise identical to that of a sizespec.
-p <ppaspec>
This option is used to specify the local and/or remote DLPI PPA(s). The PPA is used to identify the interface over which traffic is to be sent/received. The syntax of a ppaspec is otherwise the same as a sizespec.
-s sap
This option specifies the 802.2 SAP for the test. A SAP is somewhat like either the port field of a TCP or UDP header or the protocol field of an IP header. The specified SAP should not conflict with any other active SAPs on the specified PPA's (-p option).
-w <sizespec>
This option specifies the local send and receive window sizes in units of frames on those platforms which support setting such things.
-W <sizespec>
This option specifies the remote send and receive window sizes in units of frames on those platforms which support setting such things.

The DLCO_STREAM test is only present if netperf was configured with --enable-dlpi=yes. The remote netserver must have also been configured with --enable-dlpi=yes.


Next: , Previous: DLCO_STREAM, Up: Options common to TCP UDP and SCTP tests

5.2.9 DLCL_STREAM

A DLPI ConnectionLess Stream (DLCL_STREAM) test is analogous to a UDP_STREAM test in that both make use of unreliable/best-effort, connection-less transports. The DLCL_STREAM test differs from the UDP_STREAM test in that the message size (-m option) must always be less than the link MTU as there is no IP-like fragmentation and reassembly available and netperf does not presume to provide one.

The test-specific command-line options for a DLCL_STREAM test are the same as those for a DLCO_STREAM test.

The DLCL_STREAM test is only present if netperf was configured with --enable-dlpi=yes. The remote netserver must have also been configured with --enable-dlpi=yes.


Next: , Previous: DLCL_STREAM, Up: Options common to TCP UDP and SCTP tests

5.2.10 STREAM_STREAM

A Unix Domain Stream Socket Stream test (STREAM_STREAM) is similar in concept to a TCP_STREAM test, but using Unix Domain sockets. It is, naturally, limited to intra-machine traffic. A STREAM_STREAM test shares the -m, -M, -s and -S options of the other _STREAM tests. In a STREAM_STREAM test the -p option sets the directory in which the pipes will be created rather than setting a port number. The default is to create the pipes in the system default for the tempnam() call.

The STREAM_STREAM test is only present if netperf was configured with --enable-unixdomain=yes. The remote netserver must have also been configured with --enable-unixdomain=yes.


Previous: STREAM_STREAM, Up: Options common to TCP UDP and SCTP tests

5.2.11 DG_STREAM

A Unix Domain Datagram Socket Stream test (SG_STREAM) is very much like a TCP_STREAM test except that message boundaries are preserved. In this way, it may also be considered similar to certain flavors of SCTP test which can also preserve message boundaries.

All the options of a STREAM_STREAM test are applicable to a DG_STREAM test.

The DG_STREAM test is only present if netperf was configured with --enable-unixdomain=yes. The remote netserver must have also been configured with --enable-unixdomain=yes.


Next: , Previous: Using Netperf to Measure Bulk Data Transfer, Up: Top

6 Using Netperf to Measure Request/Response

Request/response performance is often overlooked, yet it is just as important as bulk-transfer performance. While things like larger socket buffers and TCP windows, and stateless offloads like TSO and LRO can cover a multitude of latency and even path-length sins, those sins cannot easily hide from a request/response test. The convention for a request/response test is to have a _RR suffix. There are however a few “request/response” tests that have other suffixes.

A request/response test, particularly synchronous, one transaction at at time test such as those found by default in netperf, is particularly sensitive to the path-length of the networking stack. An _RR test can also uncover those platforms where the NIC's are strapped by default with overbearing interrupt avoidance settings in an attempt to increase the bulk-transfer performance (or rather, decrease the CPU utilization of a bulk-transfer test). This sensitivity is most acute for small request and response sizes, such as the single-byte default for a netperf _RR test.

While a bulk-transfer test reports its results in units of bits or bytes transfered per second, by default a mumble_RR test reports transactions per second where a transaction is defined as the completed exchange of a request and a response. One can invert the transaction rate to arrive at the average round-trip latency. If one is confident about the symmetry of the connection, the average one-way latency can be taken as one-half the average round-trip latency. As of version 2.5.0 (actually slightly before) netperf still does not do the latter, but will do the former if one sets the verbosity to 2 for a classic netperf test, or includes the apropriate output selector in an omni test. It will also allow the user to switch the throughput units from transactions per secont to bits or bytes per second with the global -f option.


Next: , Previous: Using Netperf to Measure Request/Response, Up: Using Netperf to Measure Request/Response

6.1 Issues in Request/Response

Most if not all the Issues in Bulk Transfer apply to request/response. The issue of round-trip latency is even more important as netperf generally only has one transaction outstanding at a time.

A single instance of a one transaction outstanding _RR test should _never_ completely saturate the CPU of a system. If testing between otherwise evenly matched systems, the symmetric nature of a _RR test with equal request and response sizes should result in equal CPU loading on both systems. However, this may not hold true on MP systems, particularly if one CPU binds the netperf and netserver differently via the global -T option.

For smaller request and response sizes packet loss is a bigger issue as there is no opportunity for a fast retransmit or retransmission prior to a retransmission timer expiring.

Virtualization may considerably increase the effective path length of a networking stack. While this may not preclude achieving link-rate on a comparatively slow link (eg 1 Gigabit Ethernet) on a _STREAM test, it can show-up as measurably fewer transactions per second on an _RR test. However, this may still be masked by interrupt coalescing in the NIC/driver.

Certain NICs have ways to minimize the number of interrupts sent to the host. If these are strapped badly they can significantly reduce the performance of something like a single-byte request/response test. Such setups are distinguised by seriously low reported CPU utilization and what seems like a low (even if in the thousands) transaction per second rate. Also, if you run such an OS/driver combination on faster or slower hardware and do not see a corresponding change in the transaction rate, chances are good that the drvier is strapping the NIC with aggressive interrupt avoidance settings. Good for bulk throughput, but bad for latency.

Some drivers may try to automagically adjust the interrupt avoidance settings. If they are not terribly good at it, you will see considerable run-to-run variation in reported transaction rates. Particularly if you “mix-up” _STREAM and _RR tests.


Previous: Issues in Request/Response, Up: Using Netperf to Measure Request/Response

6.2 Options Common to TCP UDP and SCTP _RR tests

Many “test-specific” options are actually common across the different tests. For those tests involving TCP, UDP and SCTP, whether using the BSD Sockets or the XTI interface those common options include:

-h
Display the test-suite-specific usage string and exit. For a TCP_ or UDP_ test this will be the usage string from the source file nettest_bsd.c. For an XTI_ test, this will be the usage string from the source file src/nettest_xti.c. For an SCTP test, this will be the usage string from the source file src/nettest_sctp.c.


-H <optionspec>
Normally, the remote hostname|IP and address family information is inherited from the settings for the control connection (eg global command-line -H, -4 and/or -6 options. The test-specific -H will override those settings for the data (aka test) connection only. Settings for the control connection are left unchanged. This might be used to cause the control and data connections to take different paths through the network.


-L <optionspec>
The test-specific -L option is identical to the test-specific -H option except it affects the local hostname|IP and address family information. As with its global command-line counterpart, this is generally only useful when measuring though those evil, end-to-end breaking things called firewalls.


-P <optionspec>
Set the local and/or remote port numbers for the data connection.


-r <sizespec>
This option sets the request (first value) and/or response (second value) sizes for an _RR test. By default the units are bytes, but a suffix of “G,” “M,” or “K” will specify the units to be 2^30 (GB), 2^20 (MB) or 2^10 (KB) respectively. A suffix of “g,” “m” or “k” will specify units of 10^9, 10^6 or 10^3 bytes respectively. For example:
          -r 128,16K

Will set the request size to 128 bytes and the response size to 16 KB or 16384 bytes. [Default: 1 - a single-byte request and response ]


-s <sizespec>
This option sets the local (netperf) send and receive socket buffer sizes for the data connection to the value(s) specified. Often, this will affect the advertised and/or effective TCP or other window, but on some platforms it may not. By default the units are bytes, but a suffix of “G,” “M,” or “K” will specify the units to be 2^30 (GB), 2^20 (MB) or 2^10 (KB) respectively. A suffix of “g,” “m” or “k” will specify units of 10^9, 10^6 or 10^3 bytes respectively. For example:
          -s 128K

Will request the local send (netperf) and receive socket buffer sizes to be 128KB or 131072 bytes.

While the historic expectation is that setting the socket buffer size has a direct effect on say the TCP window, today that may not hold true for all stacks. When running under Windows a value of 0 may be used which will be an indication to the stack the user wants to enable a form of copy avoidance. [Default: -1 - use the system's default socket buffer sizes]


-S <sizespec>
This option sets the remote (netserver) send and/or receive socket buffer sizes for the data connection to the value(s) specified. Often, this will affect the advertised and/or effective TCP or other window, but on some platforms it may not. By default the units are bytes, but a suffix of “G,” “M,” or “K” will specify the units to be 2^30 (GB), 2^20 (MB) or 2^10 (KB) respectively. A suffix of “g,” “m” or “k” will specify units of 10^9, 10^6 or 10^3 bytes respectively. For example:
          -s 128K

Will request the remote (netserver) send and receive socket buffer sizes to be 128KB or 131072 bytes.

While the historic expectation is that setting the socket buffer size has a direct effect on say the TCP window, today that may not hold true for all stacks. When running under Windows a value of 0 may be used which will be an indication to the stack the user wants to enable a form of copy avoidance. [Default: -1 - use the system's default socket buffer sizes]


-4
Set the local and remote address family for the data connection to AF_INET - ie use IPv4 addressing only. Just as with their global command-line counterparts the last of the -4, -6, -H or -L option wins for their respective address families.


-6
This option is identical to its -4 cousin, but requests IPv6 addresses for the local and remote ends of the data connection.


Next: , Previous: Options Common to TCP UDP and SCTP _RR tests, Up: Options Common to TCP UDP and SCTP _RR tests

6.2.1 TCP_RR

A TCP_RR (TCP Request/Response) test is requested by passing a value of “TCP_RR” to the global -t command-line option. A TCP_RR test can be thought-of as a user-space to user-space ping with no think time - it is by default a synchronous, one transaction at a time, request/response test.

The transaction rate is the number of complete transactions exchanged divided by the length of time it took to perform those transactions.

If the two Systems Under Test are otherwise identical, a TCP_RR test with the same request and response size should be symmetric - it should not matter which way the test is run, and the CPU utilization measured should be virtually the same on each system. If not, it suggests that the CPU utilization mechanism being used may have some, well, issues measuring CPU utilization completely and accurately.

Time to establish the TCP connection is not counted in the result. If you want connection setup overheads included, you should consider the TPC_CC or TCP_CRR tests.

If specifying the -D option to set TCP_NODELAY and disable the Nagle Algorithm increases the transaction rate reported by a TCP_RR test, it implies the stack(s) over which the TCP_RR test is running have a broken implementation of the Nagle Algorithm. Likely as not they are interpreting Nagle on a segment by segment basis rather than a user send by user send basis. You should contact your stack vendor(s) to report the problem to them.

Here is an example of two systems running a basic TCP_RR test over a 10 Gigabit Ethernet link:

     netperf -t TCP_RR -H 192.168.2.125
     TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.2.125 (192.168.2.125) port 0 AF_INET
     Local /Remote
     Socket Size   Request  Resp.   Elapsed  Trans.
     Send   Recv   Size     Size    Time     Rate
     bytes  Bytes  bytes    bytes   secs.    per sec
     
     16384  87380  1        1       10.00    29150.15
     16384  87380

In this example the request and response sizes were one byte, the socket buffers were left at their defaults, and the test ran for all of 10 seconds. The transaction per second rate was rather good for the time :)


Next: , Previous: TCP_RR, Up: Options Common to TCP UDP and SCTP _RR tests

6.2.2 TCP_CC

A TCP_CC (TCP Connect/Close) test is requested by passing a value of “TCP_CC” to the global -t option. A TCP_CC test simply measures how fast the pair of systems can open and close connections between one another in a synchronous (one at a time) manner. While this is considered an _RR test, no request or response is exchanged over the connection.

The issue of TIME_WAIT reuse is an important one for a TCP_CC test. Basically, TIME_WAIT reuse is when a pair of systems churn through connections fast enough that they wrap the 16-bit port number space in less time than the length of the TIME_WAIT state. While it is indeed theoretically possible to “reuse” a connection in TIME_WAIT, the conditions under which such reuse is possible are rather rare. An attempt to reuse a connection in TIME_WAIT can result in a non-trivial delay in connection establishment.

Basically, any time the connection churn rate approaches:

Sizeof(clientportspace) / Lengthof(TIME_WAIT)

there is the risk of TIME_WAIT reuse. To minimize the chances of this happening, netperf will by default select its own client port numbers from the range of 5000 to 65535. On systems with a 60 second TIME_WAIT state, this should allow roughly 1000 transactions per second. The size of the client port space used by netperf can be controlled via the test-specific -p option, which takes a sizespec as a value setting the minimum (first value) and maximum (second value) port numbers used by netperf at the client end.

Since no requests or responses are exchanged during a TCP_CC test, only the -H, -L, -4 and -6 of the “common” test-specific options are likely to have an effect, if any, on the results. The -s and -S options _may_ have some effect if they alter the number and/or type of options carried in the TCP SYNchronize segments, such as Window Scaling or Timestamps. The -P and -r options are utterly ignored.

Since connection establishment and tear-down for TCP is not symmetric, a TCP_CC test is not symmetric in its loading of the two systems under test.


Next: , Previous: TCP_CC, Up: Options Common to TCP UDP and SCTP _RR tests

6.2.3 TCP_CRR

The TCP Connect/Request/Response (TCP_CRR) test is requested by passing a value of “TCP_CRR” to the global -t command-line option. A TCP_CRR test is like a merger of a TCP_RR and TCP_CC test which measures the performance of establishing a connection, exchanging a single request/response transaction, and tearing-down that connection. This is very much like what happens in an HTTP 1.0 or HTTP 1.1 connection when HTTP Keepalives are not used. In fact, the TCP_CRR test was added to netperf to simulate just that.

Since a request and response are exchanged the -r, -s and -S options can have an effect on the performance.

The issue of TIME_WAIT reuse exists for the TCP_CRR test just as it does for the TCP_CC test. Similarly, since connection establishment and tear-down is not symmetric, a TCP_CRR test is not symmetric even when the request and response sizes are the same.


Next: , Previous: TCP_CRR, Up: Options Common to TCP UDP and SCTP _RR tests

6.2.4 UDP_RR

A UDP Request/Response (UDP_RR) test is requested by passing a value of “UDP_RR” to a global -t option. It is very much the same as a TCP_RR test except UDP is used rather than TCP.

UDP does not provide for retransmission of lost UDP datagrams, and netperf does not add anything for that either. This means that if _any_ request or response is lost, the exchange of requests and responses will stop from that point until the test timer expires. Netperf will not really “know” this has happened - the only symptom will be a low transaction per second rate. If --enable-burst was included in the configure command and a test-specific -b option used, the UDP_RR test will “survive” the loss of requests and responses until the sum is one more than the value passed via the -b option. It will though almost certainly run more slowly.

The netperf side of a UDP_RR test will call connect() on its data socket and thenceforth use the send() and recv() socket calls. The netserver side of a UDP_RR test will not call connect() and will use recvfrom() and sendto() calls. This means that even if the request and response sizes are the same, a UDP_RR test is _not_ symmetric in its loading of the two systems under test.

Here is an example of a UDP_RR test between two otherwise identical two-CPU systems joined via a 1 Gigabit Ethernet network:

     $ netperf -T 1 -H 192.168.1.213 -t UDP_RR -c -C
     UDP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.1.213 (192.168.1.213) port 0 AF_INET
     Local /Remote
     Socket Size   Request Resp.  Elapsed Trans.   CPU    CPU    S.dem   S.dem
     Send   Recv   Size    Size   Time    Rate     local  remote local   remote
     bytes  bytes  bytes   bytes  secs.   per sec  % I    % I    us/Tr   us/Tr
     
     65535  65535  1       1      10.01   15262.48   13.90  16.11  18.221  21.116
     65535  65535

This example includes the -c and -C options to enable CPU utilization reporting and shows the asymmetry in CPU loading. The -T option was used to make sure netperf and netserver ran on a given CPU and did not move around during the test.


Next: , Previous: UDP_RR, Up: Options Common to TCP UDP and SCTP _RR tests

6.2.5 XTI_TCP_RR

An XTI_TCP_RR test is essentially the same as a TCP_RR test only using the XTI rather than BSD Sockets interface. It is requested by passing a value of “XTI_TCP_RR” to the -t global command-line option.

The test-specific options for an XTI_TCP_RR test are the same as those for a TCP_RR test with the addition of the -X <devspec> option to specify the names of the local and/or remote XTI device file(s).


Next: , Previous: XTI_TCP_RR, Up: Options Common to TCP UDP and SCTP _RR tests

6.2.6 XTI_TCP_CC

An XTI_TCP_CC test is essentially the same as a TCP_CC test, only using the XTI rather than BSD Sockets interface.

The test-specific options for an XTI_TCP_CC test are the same as those for a TCP_CC test with the addition of the -X <devspec> option to specify the names of the local and/or remote XTI device file(s).


Next: , Previous: XTI_TCP_CC, Up: Options Common to TCP UDP and SCTP _RR tests

6.2.7 XTI_TCP_CRR

The XTI_TCP_CRR test is essentially the same as a TCP_CRR test, only using the XTI rather than BSD Sockets interface.

The test-specific options for an XTI_TCP_CRR test are the same as those for a TCP_RR test with the addition of the -X <devspec> option to specify the names of the local and/or remote XTI device file(s).


Next: , Previous: XTI_TCP_CRR, Up: Options Common to TCP UDP and SCTP _RR tests

6.2.8 XTI_UDP_RR

An XTI_UDP_RR test is essentially the same as a UDP_RR test only using the XTI rather than BSD Sockets interface. It is requested by passing a value of “XTI_UDP_RR” to the -t global command-line option.

The test-specific options for an XTI_UDP_RR test are the same as those for a UDP_RR test with the addition of the -X <devspec> option to specify the name of the local and/or remote XTI device file(s).


Next: , Previous: XTI_UDP_RR, Up: Options Common to TCP UDP and SCTP _RR tests

6.2.9 DLCL_RR


Next: , Previous: DLCL_RR, Up: Options Common to TCP UDP and SCTP _RR tests

6.2.10 DLCO_RR


Previous: DLCO_RR, Up: Options Common to TCP UDP and SCTP _RR tests

6.2.11 SCTP_RR


Next: , Previous: Using Netperf to Measure Request/Response, Up: Top

7 Using Netperf to Measure Aggregate Performance

Ultimately, Netperf4 will be the preferred benchmark to use when one wants to measure aggregate performance because netperf has no support for explicit synchronization of concurrent tests. Until netperf4 is ready for prime time, one can make use of the heuristics and procedures mentioned here for the 85% solution.

Basically, there are two ways to measure aggregate performance with netperf. The first is to run multiple, concurrent netperf tests and can be applied to any of the netperf tests. The second is to configure netperf with --enable-burst and is applicable to the TCP_RR test.


Next: , Previous: Using Netperf to Measure Aggregate Performance, Up: Using Netperf to Measure Aggregate Performance

7.1 Running Concurrent Netperf Tests

Netperf4 is the preferred benchmark to use when one wants to measure aggregate performance because netperf has no support for explicit synchronization of concurrent tests. This leaves netperf2 results vulnerable to skew errors.

However, since there are times when netperf4 is unavailable it may be necessary to run netperf. The skew error can be minimized by making use of the confidence interval functionality. Then one simply launches multiple tests from the shell using a for loop or the like:

     for i in 1 2 3 4
     do
     netperf -t TCP_STREAM -H tardy.cup.hp.com -i 10 -P 0 &
     done

which will run four, concurrent TCP_STREAM tests from the system on which it is executed to tardy.cup.hp.com. Each concurrent netperf will iterate 10 times thanks to the -i option and will omit the test banners (option -P) for brevity. The output looks something like this:

      87380  16384  16384    10.03     235.15
      87380  16384  16384    10.03     235.09
      87380  16384  16384    10.03     235.38
      87380  16384  16384    10.03     233.96

We can take the sum of the results and be reasonably confident that the aggregate performance was 940 Mbits/s.

If you see warnings about netperf not achieving the confidence intervals, the best thing to do is to increase the number of iterations with -i and/or increase the run length of each iteration with -l.

You can also enable local (-c) and/or remote (-C) CPU utilization:

     for i in 1 2 3 4
     do
     netperf -t TCP_STREAM -H tardy.cup.hp.com -i 10 -P 0 -c -C &
     done
     
     87380  16384  16384    10.03       235.47   3.67     5.09     10.226  14.180
     87380  16384  16384    10.03       234.73   3.67     5.09     10.260  14.225
     87380  16384  16384    10.03       234.64   3.67     5.10     10.263  14.231
     87380  16384  16384    10.03       234.87   3.67     5.09     10.253  14.215

If the CPU utilizations reported for the same system are the same or very very close you can be reasonably confident that skew error is minimized. Presumeably one could then omit -i but that is not advised, particularly when/if the CPU utilization approaches 100 percent. In the example above we see that the CPU utilization on the local system remains the same for all four tests, and is only off by 0.01 out of 5.09 on the remote system. As the number of CPUs in the system increases, and so too the odds of saturating a single CPU, the accuracy of similar CPU utilization implying little skew error is diminished. This is also the case for those increasingly rare single CPU systems if the utilization is reported as 100% or very close to it.

NOTE: It is very important to rememeber that netperf is calculating system-wide CPU utilization. When calculating the service demand (those last two columns in the output above) each netperf assumes it is the only thing running on the system. This means that for concurrent tests the service demands reported by netperf will be wrong. One has to compute service demands for concurrent tests by hand.

If you wish you can add a unique, global -B option to each command line to append the given string to the output:

     for i in 1 2 3 4
     do
     netperf -t TCP_STREAM -H tardy.cup.hp.com -B "this is test $i" -i 10 -P 0 &
     done
     
     87380  16384  16384    10.03     234.90   this is test 4
     87380  16384  16384    10.03     234.41   this is test 2
     87380  16384  16384    10.03     235.26   this is test 1
     87380  16384  16384    10.03     235.09   this is test 3

You will notice that the tests completed in an order other than they were started from the shell. This underscores why there is a threat of skew error and why netperf4 is the preferred tool for aggregate tests. Even if you see the Netperf Contributing Editor acting to the contrary!-)


Previous: Running Concurrent Netperf Tests, Up: Running Concurrent Netperf Tests

7.1.1 Issues in Running Concurrent Tests

In addition to the aforementioned issue of skew error, there can be other issues to consider when running concurrent netperf tests.

For example, when running concurrent tests over multiple interfaces, one is not always assured that the traffic one thinks went over a given interface actually did so. In particular, the Linux networking stack takes a particularly strong stance on its following the so called ‘weak end system model’. As such, it is willing to answer ARP requests for any of its local IP addresses on any of its interfaces. If multiple interfaces are connected to the same broadcast domain, then even if they are configured into separate IP subnets there is no a priori way of knowing which interface was actually used for which connection(s). This can be addressed by setting the ‘arp_ignore’ sysctl before configuring interfaces.

As it is quite important, we will repeat that it is very important to rememeber that each concurrent netperf instance is calculating system-wide CPU utilization. When calculating the service demand each netperf assumes it is the only thing running on the system. This means that for concurrent tests the service demands reported by netperf will be wrong. One has to compute service demands for concurrent tests by hand


Previous: Running Concurrent Netperf Tests, Up: Using Netperf to Measure Aggregate Performance

7.2 Using –enable-burst

Starting in version 2.5.0 --enable-burst=yes is the default, which means one no longer must:

     configure --enable-burst

To have burst-mode functionality present in netperf. This enables a test-specific -b num option in TCP_RR, UDP_RR and omni tests.

Normally, netperf will attempt to ramp-up the number of outstanding requests to num plus one transactions in flight at one time. The ramp-up is to avoid transactions being smashed together into a smaller number of segments when the transport's congestion window (if any) is smaller at the time than what netperf wants to have outstanding at one time. If, however, the user specifies a negative value for num this ramp-up is bypassed and the burst of sends is made without consideration of transport congestion window.

This burst-mode is used as an alternative to or even in conjunction with multiple-concurrent _RR tests and as a way to implement a single-connection, bidirectional bulk-transfer test. When run with just a single instance of netperf, increasing the burst size can determine the maximum number of transactions per second which can be serviced by a single process:

     for b in 0 1 2 4 8 16 32
     do
      netperf -v 0 -t TCP_RR -B "-b $b" -H hpcpc108 -P 0 -- -b $b
     done
     
     9457.59 -b 0
     9975.37 -b 1
     10000.61 -b 2
     20084.47 -b 4
     29965.31 -b 8
     71929.27 -b 16
     109718.17 -b 32

The global -v and -P options were used to minimize the output to the single figure of merit which in this case the transaction rate. The global -B option was used to more clearly label the output, and the test-specific -b option enabled by --enable-burst increase the number of transactions in flight at one time.

Now, since the test-specific -D option was not specified to set TCP_NODELAY, the stack was free to “bundle” requests and/or responses into TCP segments as it saw fit, and since the default request and response size is one byte, there could have been some considerable bundling even in the absense of transport congestion window issues. If one wants to try to achieve a closer to one-to-one correspondence between a request and response and a TCP segment, add the test-specific -D option:

     for b in 0 1 2 4 8 16 32
     do
      netperf -v 0 -t TCP_RR -B "-b $b -D" -H hpcpc108 -P 0 -- -b $b -D
     done
     
      8695.12 -b 0 -D
      19966.48 -b 1 -D
      20691.07 -b 2 -D
      49893.58 -b 4 -D
      62057.31 -b 8 -D
      108416.88 -b 16 -D
      114411.66 -b 32 -D

You can see that this has a rather large effect on the reported transaction rate. In this particular instance, the author believes it relates to interactions between the test and interrupt coalescing settings in the driver for the NICs used.

NOTE: Even if you set the -D option that is still not a guarantee that each transaction is in its own TCP segments. You should get into the habit of verifying the relationship between the transaction rate and the packet rate via other means.

You can also combine --enable-burst functionality with concurrent netperf tests. This would then be an “aggregate of aggregates” if you like:

     
     for i in 1 2 3 4
     do
      netperf -H hpcpc108 -v 0 -P 0 -i 10 -B "aggregate $i -b 8 -D" -t TCP_RR -- -b 8 -D &
     done
     
      46668.38 aggregate 4 -b 8 -D
      44890.64 aggregate 2 -b 8 -D
      45702.04 aggregate 1 -b 8 -D
      46352.48 aggregate 3 -b 8 -D
     

Since each netperf did hit the confidence intervals, we can be reasonably certain that the aggregate transaction per second rate was the sum of all four concurrent tests, or something just shy of 184,000 transactions per second. To get some idea if that was also the packet per second rate, we could bracket that for loop with something to gather statistics and run the results through beforeafter:

     /usr/sbin/ethtool -S eth2 > before
     for i in 1 2 3 4
     do
      netperf -H 192.168.2.108 -l 60 -v 0 -P 0 -B "aggregate $i -b 8 -D" -t TCP_RR -- -b 8 -D &
     done
     wait
     /usr/sbin/ethtool -S eth2 > after
     
      52312.62 aggregate 2 -b 8 -D
      50105.65 aggregate 4 -b 8 -D
      50890.82 aggregate 1 -b 8 -D
      50869.20 aggregate 3 -b 8 -D
     
     beforeafter before after > delta
     
     grep packets delta
          rx_packets: 12251544
          tx_packets: 12251550
     

This example uses ethtool because the system being used is running Linux. Other platforms have other tools - for example HP-UX has lanadmin:

     lanadmin -g mibstats <ppa>

and of course one could instead use netstat.

The wait is important because we are launching concurrent netperfs in the background. Without it, the second ethtool command would be run before the tests finished and perhaps even before the last of them got started!

The sum of the reported transaction rates is 204178 over 60 seconds, which is a total of 12250680 transactions. Each transaction is the exchange of a request and a response, so we multiply that by 2 to arrive at 24501360.

The sum of the ethtool stats is 24503094 packets which matches what netperf was reporting very well.

Had the request or response size differed, we would need to know how it compared with the MSS for the connection.

Just for grins, here is the excercise repeated, using netstat instead of ethtool

     netstat -s -t > before
     for i in 1 2 3 4
     do
      netperf -l 60 -H 192.168.2.108 -v 0 -P 0 -B "aggregate $i -b 8 -D" -t TCP_RR -- -b 8 -D & done
     wait
     netstat -s -t > after
     
      51305.88 aggregate 4 -b 8 -D
      51847.73 aggregate 2 -b 8 -D
      50648.19 aggregate 3 -b 8 -D
      53605.86 aggregate 1 -b 8 -D
     
     beforeafter before after > delta
     
     grep segments delta
         12445708 segments received
         12445730 segments send out
         1 segments retransmited
         0 bad segments received.

The sums are left as an excercise to the reader :)

Things become considerably more complicated if there are non-trvial packet losses and/or retransmissions.

Of course all this checking is unnecessary if the test is a UDP_RR test because UDP “never” aggregates multiple sends into the same UDP datagram, and there are no ACKnowledgements in UDP. The loss of a single request or response will not bring a “burst” UDP_RR test to a screeching halt, but it will reduce the number of transactions outstanding at any one time. A “burst” UDP_RR test will come to a halt if the sum of the lost requests and responses reaches the value specified in the test-specific -b option.


Next: , Previous: Using Netperf to Measure Aggregate Performance, Up: Top

8 Using Netperf to Measure Bidirectional Transfer

There are two ways to use netperf to measure the perfomance of bidirectional transfer. The first is to run concurrent netperf tests from the command line. The second is to configure netperf with --enable-burst and use a single instance of the TCP_RR test.

While neither method is more “correct” than the other, each is doing so in different ways, and that has possible implications. For instance, using the concurrent netperf test mechanism means that multiple TCP connections and multiple processes are involved, whereas using the single instance of TCP_RR there is only one TCP connection and one process on each end. They may behave differently, especially on an MP system.


Next: , Previous: Using Netperf to Measure Bidirectional Transfer, Up: Using Netperf to Measure Bidirectional Transfer

8.1 Bidirectional Transfer with Concurrent Tests

If we had two hosts Fred and Ethel, we could simply run a netperf TCP_STREAM test on Fred pointing at Ethel, and a concurrent netperf TCP_STREAM test on Ethel pointing at Fred, but since there are no mechanisms to synchronize netperf tests and we would be starting tests from two different systems, there is a considerable risk of skew error.

Far better would be to run simultaneous TCP_STREAM and TCP_MAERTS tests from just one system, using the concepts and procedures outlined in Running Concurrent Netperf Tests. Here then is an example:

     for i in 1
     do
      netperf -H 192.168.2.108 -t TCP_STREAM -B "outbound" -i 10 -P 0 -v 0 \
        -- -s 256K -S 256K &
      netperf -H 192.168.2.108 -t TCP_MAERTS -B "inbound"  -i 10 -P 0 -v 0 \
        -- -s 256K -S 256K &
     done
     
      892.66 outbound
      891.34 inbound

We have used a for loop in the shell with just one iteration because that will be much easier to get both tests started at more or less the same time than doing it by hand. The global -P and -v options are used because we aren't interested in anything other than the throughput, and the global -B option is used to tag each output so we know which was inbound and which outbound relative to the system on which we were running netperf. Of course that sense is switched on the system running netserver :) The use of the global -i option is explained in Running Concurrent Netperf Tests.

Beginning with version 2.5.0 we can accomplish a similar result with the the omni tests and output selectors:

     for i in 1
     do
       netperf -H 192.168.1.3 -t omni -l 10 -P 0 -- \
         -d stream -s 256K -S 256K -o throughput,direction &
       netperf -H 192.168.1.3 -t omni -l 10 -P 0 -- \
         -d maerts -s 256K -S 256K -o throughput,direction &
     done
     
     805.26,Receive
     828.54,Send


Next: , Previous: Bidirectional Transfer with Concurrent Tests, Up: Using Netperf to Measure Bidirectional Transfer

8.2 Bidirectional Transfer with TCP_RR

Starting with version 2.5.0 the --enable-burst configure option defaults to yes, and starting some time before version 2.5.0 but after 2.4.0 the global -f option would affect the “throughput” reported by request/response tests. If one uses the test-specific -b option to have several “transactions” in flight at one time and the test-specific -r option to increase their size, the test looks more and more like a single-connection bidirectional transfer than a simple request/response test.

So, putting it all together one can do something like:

     netperf -f m -t TCP_RR -H 192.168.1.3 -v 2 -- -b 6 -r 32K -S 256K -S 256K
     MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.1.3 (192.168.1.3) port 0 AF_INET : interval : first burst 6
     Local /Remote
     Socket Size   Request  Resp.   Elapsed
     Send   Recv   Size     Size    Time     Throughput
     bytes  Bytes  bytes    bytes   secs.    10^6bits/sec
     
     16384  87380  32768    32768   10.00    1821.30
     524288 524288
     Alignment      Offset         RoundTrip  Trans    Throughput
     Local  Remote  Local  Remote  Latency    Rate     10^6bits/s
     Send   Recv    Send   Recv    usec/Tran  per sec  Outbound   Inbound
         8      0       0      0   2015.402   3473.252 910.492    910.492

to get a bidirectional bulk-throughput result. As one can see, the -v 2 output will include a number of interesting, related values.

NOTE: The logic behind --enable-burst is very simple, and there are no calls to poll() or select() which means we want to make sure that the send() calls will never block, or we run the risk of deadlock with each side stuck trying to call send() and neither calling recv().

Fortunately, this is easily accomplished by setting a “large enough” socket buffer size with the test-specific -s and -S options. Presently this must be performed by the user. Future versions of netperf might attempt to do this automagically, but there are some issues to be worked-out.


Previous: Bidirectional Transfer with TCP_RR, Up: Using Netperf to Measure Bidirectional Transfer

8.3 Implications of Concurrent Tests vs Burst Request/Response

There are perhaps subtle but important differences between using concurrent unidirectional tests vs a burst-mode request to measure bidirectional performance.

Broadly speaking, a single “connection” or “flow” of traffic cannot make use of the services of more than one or two CPUs at either end. Whether one or two CPUs will be used processing a flow will depend on the specifics of the stack(s) involved and whether or not the global -T option has been used to bind netperf/netserver to specific CPUs.

When using concurrent tests there will be two concurrent connections or flows, which means that upwards of four CPUs will be employed processing the packets (global -T used, no more than two if not), however, with just a single, bidirectional request/response test no more than two CPUs will be employed (only one if the global -T is not used).

If there is a CPU bottleneck on either system this may result in rather different results between the two methods.

Also, with a bidirectional request/response test there is something of a natural balance or synchronization between inbound and outbound - a response will not be sent until a request is received, and (once the burst level is reached) a subseqent request will not be sent until a response is received. This may mask favoritism in the NIC between inbound and outbound processing.

With two concurrent unidirectional tests there is no such synchronization or balance and any favoritism in the NIC may be exposed.


Next: , Previous: Using Netperf to Measure Bidirectional Transfer, Up: Top

9 The Omni Tests

Beginning with version 2.5.0, netperf begins a migration to the ‘omni’ tests or “Two routines to measure them all.” The code for the omni tests can be found in src/nettest_omni.c and the goal is to make it easier for netperf to support multiple protocols and report a great many additional things about the systems under test. Additionally, a flexible output selection mechanism is present which allows the user to chose specifically what values she wishes to have reported and in what format.

The omni tests are included by default in version 2.5.0. To disable them, one must:

     ./configure --enable-omni=no ...

and remake netperf. Remaking netserver is optional because even in 2.5.0 it has “unmigrated” netserver side routines for the classic (eg src/nettest_bsd.c) tests.


Next: , Previous: The Omni Tests, Up: The Omni Tests

9.1 Native Omni Tests

One access the omni tests “natively” by using a value of “OMNI” with the global -t test-selection option. This will then cause netperf to use the code in src/nettest_omni.c and in particular the test-specific options parser for the omni tests. The test-specific options for the omni tests are a superset of those for “classic” tests. The options added by the omni tests are:

-c
This explicitly declares that the test is to include connection establishment and tear-down as in either a TCP_CRR or TCP_CC test.


-d <direction>
This option sets the direction of the test relative to the netperf process. As of version 2.5.0 one can use the following in a case-insenstive manner:
send, stream, transmit, xmit or 2
Any of which will cause netperf to send to the netserver.
recv, receive, maerts or 4
Any of which will cause netserver to send to netperf.
rr or 6
Either of which will cause a request/response test.

Additionally, one can specify two directions separated by a '|' character and they will be OR'ed together. In this way one can use the ”Send|Recv” that will be emitted by the DIRECTION output selector when used with a request/reponse test.


-k [output selector]
This option sets the style of output to “keyval” where each line of output has the form:
          key=value

For example:

          $ netperf -t omni -- -d rr -k "THROUGHPUT,THROUGHPUT_UNITS"
          OMNI TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost.localdomain (127.0.0.1) port 0 AF_INET : demo
          THROUGHPUT=59092.65
          THROUGHPUT_UNITS=Trans/s

Using the -k option will override any previous, test-specific -o or -O option.


-o [output selector]
This option sets the style of output to “CSV” where there will be one line of comma-separated values, preceeded by one line of column names unless the global -P option is used with a value of 0:
          $ netperf -t omni -- -d rr -o "THROUGHPUT,THROUGHPUT_UNITS"
          OMNI TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost.localdomain (127.0.0.1) port 0 AF_INET : demo
          Throughput,Throughput Units
          60999.07,Trans/s

Using the -o option will override any previous, test-specific -k or -O option.


-O [output selector]
This option sets the style of output to “human readable” which will look quite similar to classic netperf output:
          $ netperf -t omni -- -d rr -O "THROUGHPUT,THROUGHPUT_UNITS"
          OMNI TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost.localdomain (127.0.0.1) port 0 AF_INET : demo
          Throughput Throughput
                     Units
          
          
          60492.57   Trans/s

Using the -O option will override any previous, test-specific -k or -o option.


-t
This option explicitly sets the socket type for the test's data connection. As of version 2.5.0 the known socket types include “stream” and “dgram” for SOCK_STREAM and SOCK_DGRAM respectively.


-T <protocol>
This option is used to explicitly set the protocol used for the test. It is case-insensitive. As of version 2.5.0 the protocols known to netperf include:
TCP
Select the Transmission Control Protocol
UDP
Select the User Datagram Procotol
SDP
Select the Sockets Direct Protocol
DCCP
Select the Datagram Congestion Control Protocol
SCTP
Select the Stream Control Transport Protocol
udplite
Select UDP Lite

The default is implicit based on other settings.

The omni tests also extend the interpretation of some of the classic, test-specific options for the BSD Sockets tests:

-m <optionspec>
This can set the send size for either or both of the netperf and netserver sides of the test:
          -m 32K

sets only the netperf-side send size to 32768 bytes, and or's-in transmit for the direction. This is effectively the same behaviour as for the classic tests.

          -m ,32K

sets only the netserver side send size to 32768 bytes and or's-in receive for the direction.

          -m 16K,32K
          sets the netperf side send size to 16284 bytes, the netserver side
          send size to 32768 bytes and the direction will be "Send|Recv."

-M <optionspec>
This can set the receive size for either or both of the netperf and netserver sides of the test:
          -M 32K

sets only the netserver side receive size to 32768 bytes and or's-in send for the test direction.

          -M ,32K

sets only the netperf side receive size to 32768 bytes and or's-in receive for the test direction.

          -M 16K,32K

sets the netserver side receive size to 16384 bytes and the netperf side receive size to 32768 bytes and the direction will be "Send|Recv."


Next: , Previous: Native Omni Tests, Up: The Omni Tests

9.2 Migrated Tests

As of version 2.5.0 several tests have been migrated to use the omni code in src/nettest_omni.c for the core of their testing. A migrated test retains all its previous output code and so should still “look and feel” just like a pre-2.5.0 test with one exception - the first line of the test banners will include the word “MIGRATED” at the beginning as in:

     $ netperf
     MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost.localdomain (127.0.0.1) port 0 AF_INET : demo
     Recv   Send    Send
     Socket Socket  Message  Elapsed
     Size   Size    Size     Time     Throughput
     bytes  bytes   bytes    secs.    10^6bits/sec
     
      87380  16384  16384    10.00    27175.27

The tests migrated in version 2.5.0 are:

It is expected that future releases will have additional tests migrated to use the “omni” functionality.

If one uses “omni-specific” test-specific options in conjunction with a migrated test, instead of using the classic output code, the new omni output code will be used. For example if one uses the -k test-specific option with a value of “MIN_LATENCY,MAX_LATENCY” with a migrated TCP_RR test one will see:

     $ netperf -t tcp_rr -- -k THROUGHPUT,THROUGHPUT_UNITS
     MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost.localdomain (127.0.0.1) port 0 AF_INET : demo
     THROUGHPUT=60074.74
     THROUGHPUT_UNITS=Trans/s

rather than:

     $ netperf -t tcp_rr
     MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost.localdomain (127.0.0.1) port 0 AF_INET : demo
     Local /Remote
     Socket Size   Request  Resp.   Elapsed  Trans.
     Send   Recv   Size     Size    Time     Rate
     bytes  Bytes  bytes    bytes   secs.    per sec
     
     16384  87380  1        1       10.00    59421.52
     16384  87380


Previous: Migrated Tests, Up: The Omni Tests

9.3 Omni Output Selection

The omni test-specific -k, -o and -O options take an optional output selector by which the user can configure what values are reported. The output selector can take several forms:

filename
The output selections will be read from the named file. Within the file there can be up to four lines of comma-separated output selectors. This controls how many multi-line blocks of output are emitted when the -O option is used. This output, while not identical to “classic” netperf output, is inspired by it. Multiple lines have no effect for -k and -o options. Putting output selections in a file can be useful when the list of selections is long.
comma and/or semi-colon-separated list
The output selections will be parsed from a comma and/or semi-colon-separated list of output selectors. When the list is given to a -O option a semi-colon specifies a new output block should be started. Semi-colons have the same meaning as commas when used with the -k or -o options. Depending on the command interpreter being used, the semi-colon may have to be escaped somehow to keep it from being interpreted by the command interpreter. This can often be done by enclosing the entire list in quotes.
all
If the keyword all is specified it means that all known output values should be displayed at the end of the test. This can be a great deal of output. As of version 2.5.0 there are 157 different output selectors.
?
If a “?” is given as the output selection, the list of all known output selectors will be displayed and no test actually run. When passed to the -O option they will be listed one per line. Otherwise they will be listed as a comma-separated list. It may be necessary to protect the “?” from the command interpreter by escaping it or enclosing it in quotes.
no selector
If nothing is given to the -k, -o or -O option then the code selects a default set of output selectors inspired by classic netperf output. The format will be the ‘human readable’ format emitted by the test-specific -O option.

The order of evaluation will first check for an output selection. If none is specified with the -k, -o or -O option netperf will select a default based on the characterists of the test. If there is an output selection, the code will first check for ‘?’, then check to see if it is the magic ‘all’ keyword. After that it will check for either ‘,’ or ‘;’ in the selection and take that to mean it is a comma and/or semi-colon-separated list. If none of those checks match, netperf will then assume the output specification is a filename and attempt to open and parse the file.


Previous: Omni Output Selection, Up: Omni Output Selection

9.3.1 Omni Output Selectors

As of version 2.5.0 the output selectors are:

OUTPUT_NONE
This is essentially a null output. For -k output it will simply add a line that reads “OUTPUT_NONE=” to the output. For -o it will cause an empty “column” to be included. For -O output it will cause extra spaces to separate “real” output.
SOCKET_TYPE
This will cause the socket type (eg SOCK_STREAM, SOCK_DGRAM) for the data connection to be output.
PROTOCOL
This will cause the protocol used for the data connection to be displayed.
DIRECTION
This will display the data flow direction relative to the netperf process. Units: Send or Recv for a unidirectional bulk-transfer test, or Send|Recv for a request/response test.
ELAPSED_TIME
This will display the elapsed time in seconds for the test.
THROUGHPUT
This will display the througput for the test. Units: As requested via the global -f option and displayed by the THROUGHPUT_UNITS output selector.
THROUGHPUT_UNITS
This will display the units for what is displayed by the THROUGHPUT output selector.
LSS_SIZE_REQ
This will display the local (netperf) send socket buffer size (aka SO_SNDBUF) requested via the command line. Units: Bytes.
LSS_SIZE
This will display the local (netperf) send socket buffer size (SO_SNDBUF) immediately after the data connection socket was created. Peculiarities of different networking stacks may lead to this differing from the size requested via the command line. Units: Bytes.
LSS_SIZE_END
This will display the local (netperf) send socket buffer size (SO_SNDBUF) immediately before the data connection socket is closed. Peculiarities of different networking stacks may lead this to differ from the size requested via the command line and/or the size immediately after the data connection socket was created. Units: Bytes.
LSR_SIZE_REQ
This will display the local (netperf) receive socket buffer size (aka SO_RCVBUF) requested via the command line. Units: Bytes.
LSR_SIZE
This will display the local (netperf) receive socket buffer size (SO_RCVBUF) immediately after the data connection socket was created. Peculiarities of different networking stacks may lead to this differing from the size requested via the command line. Units: Bytes.
LSR_SIZE_END
This will display the local (netperf) receive socket buffer size (SO_RCVBUF) immediately before the data connection socket is closed. Peculiarities of different networking stacks may lead this to differ from the size requested via the command line and/or the size immediately after the data connection socket was created. Units: Bytes.
RSS_SIZE_REQ
This will display the remote (netserver) send socket buffer size (aka SO_SNDBUF) requested via the command line. Units: Bytes.
RSS_SIZE
This will display the remote (netserver) send socket buffer size (SO_SNDBUF) immediately after the data connection socket was created. Peculiarities of different networking stacks may lead to this differing from the size requested via the command line. Units: Bytes.
RSS_SIZE_END
This will display the remote (netserver) send socket buffer size (SO_SNDBUF) immediately before the data connection socket is closed. Peculiarities of different networking stacks may lead this to differ from the size requested via the command line and/or the size immediately after the data connection socket was created. Units: Bytes.
RSR_SIZE_REQ
This will display the remote (netserver) receive socket buffer size (aka SO_RCVBUF) requested via the command line. Units: Bytes.
RSR_SIZE
This will display the remote (netserver) receive socket buffer size (SO_RCVBUF) immediately after the data connection socket was created. Peculiarities of different networking stacks may lead to this differing from the size requested via the command line. Units: Bytes.
RSR_SIZE_END
This will display the remote (netserver) receive socket buffer size (SO_RCVBUF) immediately before the data connection socket is closed. Peculiarities of different networking stacks may lead this to differ from the size requested via the command line and/or the size immediately after the data connection socket was created. Units: Bytes.
LOCAL_SEND_SIZE
This will display the size of the buffers netperf passed in any “send” calls it made on the data connection for a non-request/response test. Units: Bytes.
LOCAL_RECV_SIZE
This will display the size of the buffers netperf passed in any “receive” calls it made on the data connection for a non-request/response test. Units: Bytes.
REMOTE_SEND_SIZE
This will display the size of the buffers netserver passed in any “send” calls it made on the data connection for a non-request/response test. Units: Bytes.
REMOTE_RECV_SIZE
This will display the size of the buffers netserver passed in any “receive” calls it made on the data connection for a non-request/response test. Units: Bytes.
REQUEST_SIZE
This will display the size of the requests netperf sent in a request-response test. Units: Bytes.
RESPONSE_SIZE
This will display the size of the responses netserver sent in a request-response test. Units: Bytes.
LOCAL_CPU_UTIL
This will display the overall CPU utilization during the test as measured by netperf. Units: 0 to 100 percent.
LOCAL_CPU_METHOD
This will display the method used by netperf to measure CPU utilization. Units: single character denoting method.
LOCAL_SD
This will display the service demand, or units of CPU consumed per unit of work, as measured by netperf. Units: microsconds of CPU consumed per either KB (K==1024) of data transferred or request/response transaction.
REMOTE_CPU_UTIL
This will display the overall CPU utilization during the test as measured by netserver. Units 0 to 100 percent.
REMOTE_CPU_METHOD
This will display the method used by netserver to measure CPU utilization. Units: single character denoting method.
REMOTE_SD
This will display the service demand, or units of CPU consumed per unit of work, as measured by netserver. Units: microseconds of CPU consumed consumed per either KB (K==1024) of data transferred or request/response transaction.
SD_UNITS
This will display the units for LOCAL_SD and REMOTE_SD
CONFIDENCE_LEVEL
This will display the confidence level requested by the user either explicitly via the global -I option, or implicitly via the global -i option. The value will be either 95 or 99 if confidence intervals have been requested or 0 if they were not. Units: Percent
CONFIDENCE_INTERVAL
This will display the width of the confidence interval requested either explicitly via the global -I option or implicitly via the global -i option. Units: Width in percent of mean value computed. A value of -1.0 means that confidence intervals were not requested.
CONFIDENCE_ITERATION
This will display the number of test iterations netperf undertook, perhaps while attempting to achieve the requested confidence interval and level. If confidence intervals were requested via the command line then the value will be between 3 and 30. If confidence intervals were not requested the value will be 1. Units: Iterations
THROUGHPUT_CONFID
This will display the width of the confidence interval actually achieved for THROUGHPUT during the test. Units: Width of interval as percentage of reported throughput value.
LOCAL_CPU_CONFID
This will display the width of the confidence interval actually achieved for overall CPU utilization on the system running netperf (LOCAL_CPU_UTIL) during the test, if CPU utilization measurement was enabled. Units: Width of interval as percentage of reported CPU utilization.
REMOTE_CPU_CONFID
This will display the width of the confidence interval actually achieved for overall CPU utilization on the system running netserver (REMOTE_CPU_UTIL) during the test, if CPU utilization measurement was enabled. Units: Width of interval as percentage of reported CPU utilization.
TRANSACTION_RATE
This will display the transaction rate in transactions per second for a request/response test even if the user has requested a throughput in units of bits or bytes per second via the global -f option. It is undefined for a non-request/response test. Units: Transactions per second.
RT_LATENCY
This will display the average round-trip latency for a request/response test, accounting for number of transactions in flight at one time. It is undefined for a non-request/response test. Units: Microseconds per transaction
BURST_SIZE
This will display the “burst size” or added transactions in flight in a request/response test as requested via a test-specific -b option. The number of transactions in flight at one time will be one greater than this value. It is undefined for a non-request/response test. Units: added Transactions in flight.
LOCAL_TRANSPORT_RETRANS
This will display the number of retransmissions experienced on the data connection during the test as determined by netperf. A value of -1 means the attempt to determine the number of retransmissions failed or the concept was not valid for the given protocol or the mechanism is not known for the platform. A value of -2 means it was not attempted. As of version 2.5.0 the meaning of values are in flux and subject to change. Units: number of retransmissions.
REMOTE_TRANSPORT_RETRANS
This will display the number of retransmissions experienced on the data connection during the test as determined by netserver. A value of -1 means the attempt to determine the number of retransmissions failed or the concept was not valid for the given protocol or the mechanism is not known for the platform. A value of -2 means it was not attempted. As of version 2.5.0 the meaning of values are in flux and subject to change. Units: number of retransmissions.
TRANSPORT_MSS
This will display the Maximum Segment Size (aka MSS) or its equivalent for the protocol being used during the test. A value of -1 means either the concept of an MSS did not apply to the protocol being used, or there was an error in retrieving it. Units: Bytes.
LOCAL_SEND_THROUGHPUT
The throughput as measured by netperf for the successful “send” calls it made on the data connection. Units: as requested via the global -f option and displayed via the THROUGHPUT_UNITS output selector.
LOCAL_RECV_THROUGHPUT
The throughput as measured by netperf for the successful “receive” calls it made on the data connection. Units: as requested via the global -f option and displayed via the THROUGHPUT_UNITS output selector.
REMOTE_SEND_THROUGHPUT
The throughput as measured by netserver for the successful “send” calls it made on the data connection. Units: as requested via the global -f option and displayed via the THROUGHPUT_UNITS output selector.
REMOTE_RECV_THROUGHPUT
The throughput as measured by netserver for the successful “receive” calls it made on the data connection. Units: as requested via the global -f option and displayed via the THROUGHPUT_UNITS output selector.
LOCAL_CPU_BIND
The CPU to which netperf was bound, if at all, during the test. A value of -1 means that netperf was not explicitly bound to a CPU during the test. Units: CPU ID
LOCAL_CPU_COUNT
The number of CPUs (cores, threads) detected by netperf. Units: CPU count.
LOCAL_CPU_PEAK_UTIL
The utilization of the CPU most heavily utilized during the test, as measured by netperf. This can be used to see if any one CPU of a multi-CPU system was saturated even though the overall CPU utilization as reported by LOCAL_CPU_UTIL was low. Units: 0 to 100%
LOCAL_CPU_PEAK_ID
The id of the CPU most heavily utilized during the test as determined by netperf. Units: CPU ID.
LOCAL_CPU_MODEL
Model information for the processor(s) present on the system running netperf. Assumes all processors in the system (as perceived by netperf) on which netperf is running are the same model. Units: Text
LOCAL_CPU_FREQUENCY
The frequency of the processor(s) on the system running netperf, at the time netperf made the call. Assumes that all processors present in the system running netperf are running at the same frequency. Units: MHz
REMOTE_CPU_BIND
The CPU to which netserver was bound, if at all, during the test. A value of -1 means that netperf was not explicitly bound to a CPU during the test. Units: CPU ID
REMOTE_CPU_COUNT
The number of CPUs (cores, threads) detected by netserver. Units: CPU count.
REMOTE_CPU_PEAK_UTIL
The utilization of the CPU most heavily utilized during the test, as measured by netserver. This can be used to see if any one CPU of a multi-CPU system was saturated even though the overall CPU utilization as reported by REMOTE_CPU_UTIL was low. Units: 0 to 100%
REMOTE_CPU_PEAK_ID
The id of the CPU most heavily utilized during the test as determined by netserver. Units: CPU ID.
REMOTE_CPU_MODEL
Model information for the processor(s) present on the system running netserver. Assumes all processors in the system (as perceived by netserver) on which netserver is running are the same model. Units: Text
REMOTE_CPU_FREQUENCY
The frequency of the processor(s) on the system running netserver, at the time netserver made the call. Assumes that all processors present in the system running netserver are running at the same frequency. Units: MHz
SOURCE_PORT
The port ID/service name to which the data socket created by netperf was bound. A value of 0 means the data socket was not explicitly bound to a port number. Units: ASCII text.
SOURCE_ADDR
The name/address to which the data socket created by netperf was bound. A value of 0.0.0.0 means the data socket was not explicitly bound to an address. Units: ASCII text.
SOURCE_FAMILY
The address family to which the data socket created by netperf was bound. A value of 0 means the data socket was not explicitly bound to a given address family. Units: ASCII text.
DEST_PORT
The port ID to which the data socket created by netserver was bound. A value of 0 means the data socket was not explicitly bound to a port number. Units: ASCII text.
DEST_ADDR
The name/address of the data socket created by netserver. Units: ASCII text.
DEST_FAMILY
The address family to which the data socket created by netserver was bound. A value of 0 means the data socket was not explicitly bound to a given address family. Units: ASCII text.
LOCAL_SEND_CALLS
The number of successful “send” calls made by netperf against its data socket. Units: Calls.
LOCAL_RECV_CALLS
The number of successful “receive” calls made by netperf against its data socket. Units: Calls.
LOCAL_BYTES_PER_RECV
The average number of bytes per “receive” call made by netperf against its data socket. Units: Bytes.
LOCAL_BYTES_PER_SEND
The average number of bytes per “send” call made by netperf against its data socket. Units: Bytes.
LOCAL_BYTES_SENT
The number of bytes successfully sent by netperf through its data socket. Units: Bytes.
LOCAL_BYTES_RECVD
The number of bytes successfully received by netperf through its data socket. Units: Bytes.
LOCAL_BYTES_XFERD
The sum of bytes sent and received by netperf through its data socket. Units: Bytes.
LOCAL_SEND_OFFSET
The offset from the alignment of the buffers passed by netperf in its “send” calls. Specified via the global -o option and defaults to 0. Units: Bytes.
LOCAL_RECV_OFFSET
The offset from the alignment of the buffers passed by netperf in its “receive” calls. Specified via the global -o option and defaults to 0. Units: Bytes.
LOCAL_SEND_ALIGN
The alignment of the buffers passed by netperf in its “send” calls as specified via the global -a option. Defaults to 8. Units: Bytes.
LOCAL_RECV_ALIGN
The alignment of the buffers passed by netperf in its “receive” calls as specified via the global -a option. Defaults to 8. Units: Bytes.
LOCAL_SEND_WIDTH
The “width” of the ring of buffers through which netperf cycles as it makes its “send” calls. Defaults to one more than the local send socket buffer size divided by the send size as determined at the time the data socket is created. Can be used to make netperf more processor data cache unfiendly. Units: number of buffers.
LOCAL_RECV_WIDTH
The “width” of the ring of buffers through which netperf cycles as it makes its “receive” calls. Defaults to one more than the local receive socket buffer size divided by the receive size as determined at the time the data socket is created. Can be used to make netperf more processor data cache unfiendly. Units: number of buffers.
LOCAL_SEND_DIRTY_COUNT
The number of bytes to “dirty” (write to) before netperf makes a “send” call. Specified via the global -k option, which requires that –enable-dirty=yes was specificed with the configure command prior to building netperf. Units: Bytes.
LOCAL_RECV_DIRTY_COUNT
The number of bytes to “dirty” (write to) before netperf makes a “recv” call. Specified via the global -k option which requires that –enable-dirty was specified with the configure command prior to building netperf. Units: Bytes.
LOCAL_RECV_CLEAN_COUNT
The number of bytes netperf should read “cleanly” before making a “receive” call. Specified via the global -k option which requires that –enable-dirty was specified with configure command prior to building netperf. Clean reads start were dirty writes ended. Units: Bytes.
LOCAL_NODELAY
Indicates whether or not setting the test protocol-specific “no delay” (eg TCP_NODELAY) option on the data socket used by netperf was requested by the test-specific -D option and successful. Units: 0 means no, 1 means yes.
LOCAL_CORK
Indicates whether or not TCP_CORK was set on the data socket used by netperf as requested via the test-specific -C option. 1 means yes, 0 means no/not applicable.
REMOTE_SEND_CALLS
REMOTE_RECV_CALLS
REMOTE_BYTES_PER_RECV
REMOTE_BYTES_PER_SEND
REMOTE_BYTES_SENT
REMOTE_BYTES_RECVD
REMOTE_BYTES_XFERD
REMOTE_SEND_OFFSET
REMOTE_RECV_OFFSET
REMOTE_SEND_ALIGN
REMOTE_RECV_ALIGN
REMOTE_SEND_WIDTH
REMOTE_RECV_WIDTH
REMOTE_SEND_DIRTY_COUNT
REMOTE_RECV_DIRTY_COUNT
REMOTE_RECV_CLEAN_COUNT
REMOTE_NODELAY
REMOTE_CORK
These are all like their “LOCAL_” counterparts only for the netserver rather than netperf.
LOCAL_SYSNAME
The name of the OS (eg “Linux”) running on the system on which netperf was running. Units: ASCII Text
LOCAL_SYSTEM_MODEL
The model name of the system on which netperf was running. Units: ASCII Text.
LOCAL_RELEASE
The release name/number of the OS running on the system on which netperf was running. Units: ASCII Text
LOCAL_VERSION
The version number of the OS running on the system on which netperf was running. Units: ASCII Text
LOCAL_MACHINE
The machine architecture of the machine on which netperf was running. Units: ASCII Text.
REMOTE_SYSNAME
REMOTE_SYSTEM_MODEL
REMOTE_RELEASE
REMOTE_VERSION
REMOTE_MACHINE
These are all like their “LOCAL_” counterparts only for the netserver rather than netperf.
LOCAL_INTERFACE_NAME
The name of the probable egress interface through which the data connection went on the system running netperf. Example: eth0. Units: ASCII Text.
LOCAL_INTERFACE_VENDOR
The vendor ID of the probable egress interface through which traffic on the data connection went on the system running netperf. Units: Hexadecimal IDs as might be found in a pci.ids file or at the PCI ID Repository.
LOCAL_INTERFACE_DEVICE
The device ID of the probable egress interface through which traffic on the data connection went on the system running netperf. Units: Hexadecimal IDs as might be found in a pci.ids file or at the PCI ID Repository.
LOCAL_INTERFACE_SUBVENDOR
The sub-vendor ID of the probable egress interface through which traffic on the the data connection went on the system running netperf. Units: Hexadecimal IDs as might be found in a pci.ids file or at the PCI ID Repository.
LOCAL_INTERFACE_SUBDEVICE
The sub-device ID of the probable egress interface through which traffic on the data connection went on the system running netperf. Units: Hexadecimal IDs as might be found in a pci.ids file or at the PCI ID Repository.
LOCAL_DRIVER_NAME
The name of the driver used for the probable egress interface through which traffic on the data connection went on the system running netperf. Units: ASCII Text.
LOCAL_DRIVER_VERSION
The version string for the driver used for the probable egress interface through which traffic on the data connection went on the system running netperf. Units: ASCII Text.
LOCAL_DRIVER_FIRMWARE
The firmware version for the driver used for the probable egress interface through which traffic on the data connection went on the system running netperf. Units: ASCII Text.
LOCAL_DRIVER_BUS
The bus address of the probable egress interface through which traffic on the data connection went on the system running netperf. Units: ASCII Text.
LOCAL_INTERFACE_SLOT
The slot ID of the probable egress interface through which traffic on the data connection went on the system running netperf. Units: ASCII Text.
REMOTE_INTERFACE_NAME
REMOTE_INTERFACE_VENDOR
REMOTE_INTERFACE_DEVICE
REMOTE_INTERFACE_SUBVENDOR
REMOTE_INTERFACE_SUBDEVICE
REMOTE_DRIVER_NAME
REMOTE_DRIVER_VERSION
REMOTE_DRIVER_FIRMWARE
REMOTE_DRIVER_BUS
REMOTE_INTERFACE_SLOT
These are all like their “LOCAL_” counterparts only for the netserver rather than netperf.
LOCAL_INTERVAL_USECS
The interval at which bursts of operations (sends, receives, transactions) were attempted by netperf. Specified by the global -w option which requires –enable-intervals to have been specified with the configure command prior to building netperf. Units: Microseconds (though specified by default in milliseconds on the command line)
LOCAL_INTERVAL_BURST
The number of operations (sends, receives, transactions depending on the test) which were attempted by netperf each LOCAL_INTERVAL_USECS units of time. Specified by the global -b option which requires –enable-intervals to have been specified with the configure command prior to building netperf. Units: number of operations per burst.
REMOTE_INTERVAL_USECS
The interval at which bursts of operations (sends, receives, transactions) were attempted by netserver. Specified by the global -w option which requires –enable-intervals to have been specified with the configure command prior to building netperf. Units: Microseconds (though specified by default in milliseconds on the command line)
REMOTE_INTERVAL_BURST
The number of operations (sends, receives, transactions depending on the test) which were attempted by netperf each LOCAL_INTERVAL_USECS units of time. Specified by the global -b option which requires –enable-intervals to have been specified with the configure command prior to building netperf. Units: number of operations per burst.
LOCAL_SECURITY_TYPE_ID
LOCAL_SECURITY_TYPE
LOCAL_SECURITY_ENABLED_NUM
LOCAL_SECURITY_ENABLED
LOCAL_SECURITY_SPECIFIC
REMOTE_SECURITY_TYPE_ID
REMOTE_SECURITY_TYPE
REMOTE_SECURITY_ENABLED_NUM
REMOTE_SECURITY_ENABLED
REMOTE_SECURITY_SPECIFIC
A bunch of stuff related to what sort of security mechanisms (eg SELINUX) were enabled on the systems during the test.
RESULT_BRAND
The string specified by the user with the global -B option. Units: ASCII Text.
UUID
The universally unique identifier associated with this test, either generated automagically by netperf, or passed to netperf via an omni test-specific -u option. Note: Future versions may make this a global command-line option. Units: ASCII Text.
MIN_LATENCY
The minimum “latency” or operation time (send, receive or request/response exchange depending on the test) as measured on the netperf side when the global -j option was specified. Units: Microseconds.
MAX_LATENCY
The maximum “latency” or operation time (send, receive or request/response exchange depending on the test) as measured on the netperf side when the global -j option was specified. Units: Microseconds.
P50_LATENCY
The 50th percentile value of “latency” or operation time (send, receive or request/response exchange depending on the test) as measured on the netperf side when the global -j option was specified. Units: Microseconds.
P90_LATENCY
The 90th percentile value of “latency” or operation time (send, receive or request/response exchange depending on the test) as measured on the netperf side when the global -j option was specified. Units: Microseconds.
P99_LATENCY
The 99th percentile value of “latency” or operation time (send, receive or request/response exchange depending on the test) as measured on the netperf side when the global -j option was specified. Units: Microseconds.
MEAN_LATENCY
The average “latency” or operation time (send, receive or request/response exchange depending on the test) as measured on the netperf side when the global -j option was specified. Units: Microseconds.
STDDEV_LATENCY
The standard deviation of “latency” or operation time (send, receive or request/response exchange depending on the test) as measured on the netperf side when the global -j option was specified. Units: Microseconds.
COMMAND_LINE
The full command line used when invoking netperf. Units: ASCII Text.
OUTPUT_END
While emitted with the list of output selectors, it is ignored when specified as an output selector.


Next: , Previous: The Omni Tests, Up: Top

10 Other Netperf Tests

Apart from the typical performance tests, netperf contains some tests which can be used to streamline measurements and reporting. These include CPU rate calibration (present) and host identification (future enhancement).


Next: , Previous: Other Netperf Tests, Up: Other Netperf Tests

10.1 CPU rate calibration

Some of the CPU utilization measurement mechanisms of netperf work by comparing the rate at which some counter increments when the system is idle with the rate at which that same counter increments when the system is running a netperf test. The ratio of those rates is used to arrive at a CPU utilization percentage.

This means that netperf must know the rate at which the counter increments when the system is presumed to be “idle.” If it does not know the rate, netperf will measure it before starting a data transfer test. This calibration step takes 40 seconds for each of the local or remote ystems, and if repeated for each netperf test would make taking repeated measurements rather slow.

Thus, the netperf CPU utilization options -c and and -C can take an optional calibration value. This value is used as the “idle rate” and the calibration step is not performed. To determine the idle rate, netperf can be used to run special tests which only report the value of the calibration - they are the LOC_CPU and REM_CPU tests. These return the calibration value for the local and remote system respectively. A common way to use these tests is to store their results into an environment variable and use that in subsequent netperf commands:

     LOC_RATE=`netperf -t LOC_CPU`
     REM_RATE=`netperf -H <remote> -t REM_CPU`
     netperf -H <remote> -c $LOC_RATE -C $REM_RATE ... -- ...
     ...
     netperf -H <remote> -c $LOC_RATE -C $REM_RATE ... -- ...

If you are going to use netperf to measure aggregate results, it is important to use the LOC_CPU and REM_CPU tests to get the calibration values first to avoid issues with some of the aggregate netperf tests transferring data while others are “idle” and getting bogus calibration values. When running aggregate tests, it is very important to remember that any one instance of netperf does not know about the other instances of netperf. It will report global CPU utilization and will calculate service demand believing it was the only thing causing that CPU utilization. So, you can use the CPU utilization reported by netperf in an aggregate test, but you have to calculate service demands by hand.


Previous: CPU rate calibration, Up: Other Netperf Tests

10.2 UUID Generation

Beginning with version 2.5.0 netperf can generate Universally Unique IDentifiers (UUIDs). This can be done explicitly via the “UUID” test:

     $ netperf -t UUID
     2c8561ae-9ebd-11e0-a297-0f5bfa0349d0

In and of itself, this is not terribly useful, but used in conjuction with the test-specific -u option of an “omni” test to set the UUID emitted by the UUID output selector, it can be used to tie-together the separate instances of an aggregate netperf test. Say, for instance if they were inserted into a database of some sort.


Next: , Previous: Other Netperf Tests, Up: Top

11 Address Resolution

Netperf versions 2.4.0 and later have merged IPv4 and IPv6 tests so the functionality of the tests in src/nettest_ipv6.c has been subsumed into the tests in src/nettest_bsd.c This has been accomplished in part by switching from gethostbyname()to getaddrinfo() exclusively. While it was theoretically possible to get multiple results for a hostname from gethostbyname() it was generally unlikely and netperf's ignoring of the second and later results was not much of an issue.

Now with getaddrinfo and particularly with AF_UNSPEC it is increasingly likely that a given hostname will have multiple associated addresses. The establish_control() routine of src/netlib.c will indeed attempt to chose from among all the matching IP addresses when establishing the control connection. Netperf does not _really_ care if the control connection is IPv4 or IPv6 or even mixed on either end.

However, the individual tests still ass-u-me that the first result in the address list is the one to be used. Whether or not this will turn-out to be an issue has yet to be determined.

If you do run into problems with this, the easiest workaround is to specify IP addresses for the data connection explicitly in the test-specific -H and -L options. At some point, the netperf tests _may_ try to be more sophisticated in their parsing of returns from getaddrinfo() - straw-man patches to netperf-feedback@netperf.org would of course be most welcome :)

Netperf has leveraged code from other open-source projects with amenable licensing to provide a replacement getaddrinfo() call on those platforms where the configure script believes there is no native getaddrinfo call. As of this writing, the replacement getaddrinfo() as been tested on HP-UX 11.0 and then presumed to run elsewhere.


Next: , Previous: Address Resolution, Up: Top

12 Enhancing Netperf

Netperf is constantly evolving. If you find you want to make enhancements to netperf, by all means do so. If you wish to add a new “suite” of tests to netperf the general idea is to:

  1. Add files src/nettest_mumble.c and src/nettest_mumble.h where mumble is replaced with something meaningful for the test-suite.
  2. Add support for an apropriate --enable-mumble option in configure.ac.
  3. Edit src/netperf.c, netsh.c, and netserver.c as required, using #ifdef WANT_MUMBLE.
  4. Compile and test

However, with the addition of the “omni” tests in version 2.5.0 it is preferred that one attempt to make the necessary changes to src/nettest_omni.c rather than adding new source files, unless this would make the omni tests entirely too complicated.

If you wish to submit your changes for possible inclusion into the mainline sources, please try to base your changes on the latest available sources. (See Getting Netperf Bits.) and then send email describing the changes at a high level to netperf-feedback@netperf.org or perhaps netperf-talk@netperf.org. If the concensus is positive, then sending context diff results to netperf-feedback@netperf.org is the next step. From that point, it is a matter of pestering the Netperf Contributing Editor until he gets the changes incorporated :)


Next: , Previous: Enhancing Netperf, Up: Top

13 Netperf4

Netperf4 is the shorthand name given to version 4.X.X of netperf. This is really a separate benchmark more than a newer version of netperf, but it is a decendant of netperf so the netperf name is kept. The facetious way to describe netperf4 is to say it is the egg-laying-woolly-milk-pig version of netperf :) The more respectful way to describe it is to say it is the version of netperf with support for synchronized, multiple-thread, multiple-test, multiple-system, network-oriented benchmarking.

Netperf4 is still undergoing evolution. Those wishing to work with or on netperf4 are encouraged to join the netperf-dev mailing list and/or peruse the current sources.


Next: , Previous: Netperf4, Up: Top

Concept Index


Previous: Concept Index, Up: Top

Option Index

0707010003bba2000081a40000000000000000000000014f45c4ce0000a7ce000000b500010002ffffffffffffffff0000002f00000000root/usr/local/share/doc/netperf/Release_NotesThese are the Release Notes for Revision 2.5.0 of netperf: *) Add a new -N option to netserver which will suppress all creation of debug files and so debugging output. While this would put a serious crimp in debugging a problem in netserver, it will enable folks using small embedded systems to avoid soaking-up their /tmp filesystem with clutter. *) A refactoring and partial re-write of the src/netserver.c code to untangle years of accumulated spaghetti code. Included is the ability to not daemonize netserver when launched from the command-line (-D) and also to not fork/spawn child processes upon the acceptance of a control connection (-f). Combined, the two options will cause netserver to remain in the forground and not spawn children - in effect netserver will handle only one test at a time. *) As it has been two years since the defect in Solaris getaddrinfo() was submitted, it should be the case that a fix is available, so it should no longer be necessary to "hide" the "Hey your platform's getaddrinfo() call is buggy" warning. Consequently, it is no longer being suppressed. *) A new global command line option - -S - has been added to enable setting of SO_KEEPALIVE on the data socket. This will affect the netperf side of the "classic" netperf tests, and will also affect the netserver side of an "omni" or migrated classic test as only the control message for the omni tests has the requisite flags field to communicate the desire to set SO_KEEPALIVE. Ostensibly, this may help when netperf is (ab)used in functional testing situations and netservers end-up orphaned and out in the cold because their corresponding netperfs went away and the notification was lost amid the roar of traffic over-saturating the interconnect(s). The default is to behave as before - SO_KEEPALIVE not set. *) Base on the frequency at which the author has used the functionality, the default for --enable-burst is now "yes." To disable support for burst mode one must now include a --enable-burst=no when performing the ./configure prior to compiling the bits. *) The output of the -D global command line option (./configure --enable-demo) has been enhanced to include seconds and milliseconds since the epoch as returned by a gettimeofday() call with a null pointer for the timezone. This is in support of being able to easily shove interim results into an rrdtool Round-Robin Database (RRD). *) The "omni" tests will be compiled-in by default, and WANT_MIGRATION is the default. One must ./configure with --enable-omni=no to disable this. *) When ./configured with --enable-intervals and intervals are actually used, the round-trip latency reported by an omni (or migrated classic) request/response test should better reflect reality rather than the length of the pacing interval. It and the MEAN_LATENCY from the histogram and -j output will still differ slightly and probably always will. *) The histogram code has been enhanced to track more than one latency at a time and so --enable-histogram and --enable-burst are now compatible - for the omni tests or migrated "classic" tests only however. This change was inspired/instigated by Jim Gettys and his work on overly-large queues of buffers *) WANT_MIGRATION is enabled when one specifies --enable-omni on the configure command line. *) Massage and encorporate a patch from Google that enables randomization of the IP addresses used in a test. An optional mask length in the standard '/' notation can be added to the end of the IP/name in the test-specific -H or -L options of an Omni test. *) Massage and include a DEBUG_LOG_FILE patch for Android from Josselin Costanzi *) Add intial attempt to report Slot ID on HP-UX 11.31. *) Add global -s option to cause omni tests to pause between setting-up the test and actually starting it. pause is in seconds. Poor man's way to (attempt to) avoid issues when starting many, Many, MANY concurrent netperf tests. Based on patches from Google. *) Additional timing statistics will be kept by the omni tests when the global "-j" option is specified. The additional statistics are min, max, mean, stddev and the 50th, 90th and 99th percentiles on the timings measured by histograms. Based on patches from Google. *) Add a workaround to get Linux to report TX queue drops in a UDP_STREAM test when the socket buffer size is larger than the TX queue. Provided by Andrew Gallatin. *) Fix the configure script to know it does not have to look for an SCTP library on FreeBSD 8.X *) The BSD and "omni" tests now have a test-specific -R option which is a boolean controlling whether or not SO_DONTROUTE will be set on the data socket. By default, any unidirectional UDP test will have SO_DONTROUTE set unless a -R 1 option is given. All other tests (including UDP request/response tests) will not have SO_DONTROUTE set unless a -R 0 option is given. This is put into place to make it take longer for blithering idiots to shoot themselves in the foot by running tests on setups they shouldn't. *) At least the beginnings of support for RDS, based on a circa 2007 patch against 2.4.2 by Vladimir Sokolovsky. Rather than create the "RDS_STREAM" test of his patch, the intention this time around is to enable RDS for the "omni" tests by using an omni test-specific -T rds specifyer for the "transport" to use. *) Missing fprintf format statements provided by Bruno Cornec *) Numerous cleanups from Jose Pedro Oliveira *) Fixes to allow netperf -H ::1 to work without having to add -6 or an AF_INET6 -L option These are the Release Notes for Revision 2.4.5 of netperf: Things changed in this release: *) Fixes for Linux procstat-based CPU utilization on newer kernels from Andrew Gallatin. *) Fix for a TCP_RR hang from Michael Shuldman *) Compilation cleanups for MingW cnd MSDOS (djgpp) ourtesy of Gisle Vanem. *) Changes to enable compilation and building of netperf for VMware. Kudos to the person who did the first port, I will be happy to name that person when told it is OK :) *) Fixes from Adam Bidema for launching netserver children when the path to netserver.exe is very long. *) For the first time, netperf2 has a dependency, albeit optional, on another non-base-os bit of code - libsmbios under Linux. It will attept to detect this at compile time and use it to report the system model name in an omni test. If libsmbios is there we will try to use it, otherwise we will not. If the associated include file is also there (eg the -dev package in apt-get-speak), we will use it to get the prototype for SMBIOSGetSystemName, otherwise we make a guess as to the prototype for SMBIOSGetSystemName(), which is the only call we make to libsmbios. *) Fixes for BSD CPU utilization to deal with different BSD variants using different types. Courtesy of Simon Burge *) The "omni" suite has been added on an experimental basis. If it works-out then many of the tests in src/nettest_bsd.c, src/nettest_sdp.c, and src/nettest_sctp.c will be "migrated" to use the "omni infrastructure" (aka two routines to measure them all...). Apart from reduced socket code, the omni suite has user-configurable output in either "human readable," CSV or keyword=value format. By default, a VERY large quantity of data is output when asking for csv format (test-specific -o option) or keyword format (test-specific -k option). The omni suite is not yet documented (there are some as-yet undiagnosed problems with doc/netperf.texi in emacs texinfo mode and updating nodes and links and such - any help there would be appreciated) but there is a small text file in doc/ describing the names (most) of the available output's. For the most up-to-date list consult src/nettest_omni.c and the enum netperf_output_name. Or, you can pass-in a "filename" of '?' to either of the -O, -o or -k options and netperf will emit a list of the known available outputs. *) Coming along for the ride are some new platform specific files to determine the probable egress interface for each end of a test, as well as driver information for that interface. There is also reporting of "uname" like information for both local and remote system, and eventually perhaps something about the vendor's model name for the systems as well as the processor types. The end goal is to make it easy to get most if not all what one would want in a database of netperf results. *) The UDP_RR test now understands the global -f option to change output units. It also understands the -B option to tag results. Courtesy of Alexander Duyck. *) A fix has been added for hanging UDP_RR tests under Windows. Courtesy of Alexander Duyck. *) Use vfork() on those platforms without fork(), courtesy of Matt Waddel *) Track the bouncing interfaces that are linux processor affinity *) Fixes for Solaris sendfilev usage. *) A TCP_MSS test has been added which will report the MSS for a data connection setup as if the test were a TCP_STREAM test. While the remote (netserver) is tricked into thinking it is to accept a TCP_STREAM test, no actual data will flow over the connection. This means that if the MSS is one which might change over the life of the connection, it will not be reflected in the test output. Should this prove to be a problem a single send() can be arranged along with the return of the shutdown();recv() handshake. The idea is that this might be useful for netperf scripts wanting to parameterize things based on the MSS - for example the packet_byte_script. *) The width of the confidence interval can be specified in fractions of a percent for the confidence of a clean, close, comfortable calculation. :) *) Honor the global -B option in a TCP_SENDFILE test. *) Correct the sense of Send/Recv in the banner of a TCP_MAERTS test. These are the Release Notes for Revision 2.4.4 of netperf: Things changed in this release: *) The LOC_CPU and REM_CPU tests will report their respective beliefs as to the number of CPUs present when the verbosity is set to more than one. This can be used when trying to diagnose issues with CPU utilization. *) A kind soul who wishes to remain anonymous provided a patch to enable use of sendfile() on OSX. *) Fix a misplaced \n in a format string of send_tcp_maerts, courtesy of Alexander Duyck. *) There is an experimental global -r option which will allow one to include CPU utilization measurements, but make the decision about hitting confidence based on the result only. The test banner will reflects this when -r is used. *) It is no longer necessary to specify a file with the global -F option when running a _SENDFILE test. Netperf will create a temporary file and populate it with random data and use that. If running aggregate tests it is strongly suggested one use a -F option. Otherwise, the overhead spent creating and populating the temporary file will be included in the CPU utilization calculation. *) The configure script recognizes Solaris 11 and selects the correct CPU utilization mechanism - or rather it selects the same mechanism as is used in Solaris 10. Fix courtesy of Andrew Gallatin. *) Convert a number of struct sockaddr_in's to struct sockaddr_storage's and add requisite casts to deal with some abort problems on Windows and perhaps other platforms as well. Kudos to Alexander Duyck. *) One can now pass a value of 'x' to the global -f option to specify the units as transactions per second. This is the default for any request/response test, which is determined by there being a "double `r'" in the name - eg "RR," "rr," "Rr," or "rR." At present only the TCP_RR test actually looks for this to be set. *) One can request bits/bytes per second as the primary output of a TCP_RR test by setting the global -f option to [kmgKMG] as with any of the "STREAM" tests. This converts the primary throughput metric to a bitrate (byterate) following the verbosity rules for a STREAM test. Service demand remains usec/Transaction regardless of the setting of the global -f option. A verbosity level of 2 or more will cause the TCP_RR test to report calculated average RTT latency, transaction rate, and inbound and outbound transfer rates regardless of the primary units selected with the global -f paramter. If the primary output is transactions per second, the reported inbound and outbound transfer rates will be 10^6 bits per second, otherwise, they honor the setting of the global -f option. All of this is EXPERIMENTAL and subject to change without prior notice in future versions of netperf. *) Replace "break" with "break 2" in acinclude.m4 for a socklen macro *) The default for the requested socket buffer size is changed from 0 to -1 to enable passing a value of 0 under Windows, which tells that stack one wishes to enable copy-avoidance. *) Call fflush() on each interim result displayed in demo mode to make things happier for folks redirecting same to a file. From Dan Yost. *) In theory each distinct netserver child will have a debug log with its pid appended to the name, somewhat like what appears to happen under Windows. *) A new global, command-line option to netperf and netserver has been added. The -V option will cause netperf/netserver to display its version and exit. *) Setting -I without setting -i will now implicitly set the iteration minimum and maximums as if a -i 10,3 were set. Also, some further sanity checking on the bounds for each is made. *) Fixed a typo in the manual (found by Emir Halepovic) so the description for the -s and -S options properly specifies they affect the data connection. These are the Release Notes for Revision 2.4.3 of netperf: Things changed in this release: *) The UDP_STREAM test includes --enable-demo support, courtesy of patches from Scott Weitzenkamp. *) The nettest_dns.* files have been removed from the release and the repository. Those wishing to perform DNS server tests should migrate to netperf4 which has better support for DNS test. *) Fixes for compiling under Windows with Mingw/gcc courtesy of Gisle Vanem. *) A new global option - -N - has been added. When specified, this option will tell netperf to not bother to try to establish a control connection with a remote netserver. Instead, netperf will only attempt to make a data connection to the remote system. By default, this will be to the "discard" service for a "STREAM" or "SENDFILE" test, the "echo" service for a "RR" test and the "chargen" service for a "MAERTS" test. Any "remote" settings are changed to reflect their being unused in the test, and a "no control" tag is added to the test banner when -N is specified. This still needs to be propagated to other test files - at least for those for which it may make sense. *) The tests in nettest_bsd.c have been altered to not actually take timestamps and deltas in --enable-histogram unless the verbosity level has been set to actually display a histogram. This reduces the overhead measurably, even on systems with "fast" time calls, which _may_ mean that a future release of netperf may have histogram support enabled by default. This still needs to be propagated to other test files. Patches from the community would be most welcome :) *) Eliminate a bogus fprintf from the signal catching routine which was being executed when both intervals and demo mode were active at the same time. *) The nettest_ipv6.* files are no longer included in the source tar/zip file. IPv6 functionality has been subsumed into the nettest_bsd.* files for some time now. *) Use a higher resolution "time" source for HISTOGRAM support under Windows, courtesy of Spencer Frink. Prior to this it had no better than 10ms granularity which could lead to some rather strange looking results :) *) A bug fix reporting recv_size rather than send_size in TCP_MAERTS when CPU utilization was requested. *) A bug fix for buffer filling from a file to properly advance the buffer pointer when the file is smaller than the send buffer. *) Enable certain UDP tests which previously used unconnected sockets to use connected sockets. Courtesy of Shilpi Agarwal. *) The OSX CPU utilization code actually gets put into the tarball in a make dist now :) *) The check to make sure that getaddrinfo returned ai_protocol and/or ai_socktype's matching that which we requested is done for all socket and/or protocol types and a warning is emitted if it returns any which do not match. *) The linux CPU affinity code has been made capable of binding to CPU's >=32 on a 32-bit compilation and >=64 on a 64-bit compilation. *) More complete closing/redirecting of stdin/stdout/stderr/where in netserver to make it easier to launch netserver at the far-end of a remote shell. Courtesy of Hans Blom. *) Sendfile changes for Solaris courtesy of Andrew Gallatin. *) "spec" file support to generate RPMs courtesy of Martin Brown These are the Release Notes for Revision 2.4.2 of netperf: Things changed in this release: *) Fixes for floating point format differences, courtesy of George Davis. *) Additions for CPU util support on MacOS X, courtesy of Anonymous. *) Processor affinity is now supported on AIX 5.3 (perhaps earlier) via the bindprocessor system call. *) Fixes for test lockups with TCP_CRR and TCP_CC under Windows courtesy of Dikon Reed. *) Fixes to netcpu_looper.c to get it to actually compile :) *) Have netcpu_looper use the bind_to_specific_processor() call provided by netlib since that knows about more platforms than the code in netcpu_looper did. The looper CPU binding will use a mapping to handle cases where the CPU id's on the system may not be a contiguous space starting from zero. At present, the code that setups the mapping only knows about retrieving actual CPU ids under HP-UX. *) The netcpu_sysctl method becomes calibration-free, courtesy of Andrew Gallatin These are the Release Notes for Revision 2.4.1 of netperf: Things changed in this release: *) There is now a -B global command-line argument that will append its parameter as a string to the end of result lines when test banners have been suppressed. this is to make it easier to distinguish one result from another when aggregate restults are being run in parallel, without having to resort to having the individual results shell redirected to a file. This has been done for some of the tests in nettest_bsd.c, but not all of them, nor for the tests in the other nettest_mumble.c files. *) There is now an --enable-spin configure option that will enable intervals if not already enabled and will have the sender sit and spin in a tight loop until time for the next interval rather than wait for an interval timer to expire. This means it should be possible to have a much finer granularity on the interval, at the expense of an EXTREME increase in CPU utilization. (To the extent I'm considering disabling measurement of local CPU utilization when that mode is enabled, and bursts have been requested - your feedback on that topic would be most appreciated) If only --enable-intervals is used with configure, the old set the interval timer and wait method is still used. If --enable-spin is configured, the test banner will include "spin intervals" rather than the "intervals" from a plain --enable-intervals. The sit and spin will either use gettimeofday(), or gethrtime() if gethrtime() is available. This has been implemented in the tests of nettest_bsd.c but none of the others. Volunteers would be most welcome. I would entertain the notion of making the implementation a series of inline functions in netlib. This holds true for the demo mode - why will become clear when you look at nettest_bsd.c. While things are considerably cleaner than they were before, with reuse within nettest_bsd.c, there is no resuse with the rest of the nettest_mumble.c files. *) the -w option for the interval time now takes three optional suffixes. if the suffix is 'm' (eg 10m) it will assume the user has specified time in units of milliseconds. if the suffix is 'u' it will assume microseconds, and if 's' seconds. no suffix remains milliseconds for backwards compatability with previous netperf versions. *) It should be possible to successfully compile with --enable-intervals. These are the Release Notes for Revision 2.4.1 of netperf: Things changed in this release: *) netcpu_pstatnew.c has been altered to workaround a bug in the interrupt cycle accounting in HP-UX 11.23 that is not expected to be resolved until a later release. basically, some interrupt time is not counted, which means the sum of idle, user, kernel and interrupt is less than the cycles per second multiplied by the elapsed time. the workaround preserves the "no calibration required" nature of the pstatnew CPU utilization mechanism. you can see more in netcpu_pstatnew.c and/or in debug output. *) in netlib.c recv_response has been renamed recv_response_timed(addl_time) which is now used in calibrate_remote_cpu in place of the "sleep(40);recv_response()" sequence. This then allows the REM_CPU test to complete in less than 40 seconds when the remote's CPU utilization mechanism does not require calibration. The value of "addl_time" is added to the tc_sec field of the select() timeout. A "new" recv_response has been added that simply calls recv_response_timed(0) - this is to minimize the number of changes needed elsewhere in the code. *) hopefully, this release fixes problems people have been having with the configure script failing when picking a type for socklen_t. now, instead of generating an error, it emits a warning and simply tries socklen_t *) the configure script no longer looks for the size of an in_port_t *) netlib.c now has code to perform processor binding for Tru64, but the configure script may or may not detect it correctly. This means that one may have to edit the config.h file by hand to get the functionality. *) it is known that netperf will compile under Windows XP and 2003 using the DDK it is possible that netperf 2.4.1 will compile on a Windows system under VC++/Visual Studio. It might even work!-) See the README.window file for additional details. Things _NOT_ changed in this release: *) The automagic determination of the number and type of parameters to sched_setaffinity under Linux remains brittle at best. These are the Release Notes for Revision 2.4.0 of netperf: Things changed in this release: *) Netperf has been converted to use a configure script. Yes boys and girls, after 12 years of distributing netperf with just a makefile I have finally bitten the bullet and cast my fate to autoconf, automake, etc. To get the most basic netperf built all you should need to do is: cd to the netperf directory ./configure make and perhaps make install (Note, I've not done much with make install - I'm hemming and hawing over what the default installation location should be) Please keep in mind that this is the first time I've tried to use autoconf et al. I am sure there are things that should be done differently and would welcome any and all constructive criticisms. I suspect there are several places where I've not fully demonstrated being of the autoconf body - particulary as pertains to include files being in "#if mumble #endif" blocks. Fixes would be most welcome. *) Speaking of becomming one with various GNU tools, work on a new netperf manual has begun, with the source being a texinfo document that is converted to "all" the other formats. This resides in doc/ . *) The platform-specific parts of CPU utilization measurement have been broken-out into separate .c files and selected at configure time a la the pcap_mumble files of tcpdump. This makes src/netlib.c _much_ easier to read and the addition of new CPU utilization mechanisms much easier. *) New HP-UX 11.23 and Solaris 10 CPU utilization measurement mechanisms (called pstatnew and kstat10 respectively) need no calibration step. Both have variations on microstate accounting. HP-UX 11.23 still identifies the method in the headers as 'P' for pstat. The kstat10 method is identified as 'M' for Microstate. Scripts which make calibration runs with LOC_CPU and REM_CPU may continue to do so, they will just run forty to eighty seconds faster on platforms with the calibration-free CPU util mechanisms. *) Automatic detection of CPU utilization mechanism for HP-UX, Linux, AIX, *BSD and Solaris. If you do not like what the configure script selects, you can use --enable-cpuutil= . *) The "times" (aka 'T') CPU utilization mechanism has been removed. It was never very accurate at all, only showing CPU time charged to the process, and with interrupts and other network processing it is rarely chaged to a or the correct process. It and other methods may remain in the format_cpu_method() routine of src/netlib.c for historical purposes only. *) CAVEAT - the "kstat" mechanism is KNOWN TO BE BOGUS for Solaris. It does not include time spent processing interrupts, and networking benchmarks will generate at least a few of those... This affects _ALL_ versions of Solaris with kstat. So, do NOT trust any CPU util figures where netperf says the method was 'K' for kstat - unless perhaps it reports 100% CPU util. Solaris 10 takes a step in the right direction adding microstate accounting similar to what netperf uses on HP-UX 11.23. HOWEVER, Solaris 10's accounting for user/kernel/idle is done in _parallel_ with interrupt, which means they overlap. Doubleplusungood. Netperf attempts to compensate for that with some handwaving (src/netcpu_kstat10.c) *) Initial support for SCTP has been added with the SCTP_STREAM and SCTP_RR tests. These tests use the libsctp mechanisms for increased portability. It has been explained that libsctp should not impart all that much overhead and it does make things rather simpler. *) Netperf now uses getaddrinfo() to resolve hostnames and IP addresses. A replacement getaddrinfo() is provided for those platforms where the configure script cannot tell that getaddrinfo is present. There are cases where a host's getaddrinfo call may return results that ignore the hints for protocol. Netperf catches these and reports a warning so you can pester your OS source for fixes. Solaris getaddrinfo() seems to return results with SCTP procotol cleared. Mac OS X getaddrinfo botches when the service/port is specified as "0" so one must specify a port number on the netperf command line. AIX 5.something getaddrinfo has a different but similar problem with "0" as a port/service name as well. Linux 2.6 and HP-UX 11i getaddrinfo seem to be fine - at least as far as netperf goes :) *) A "Demo Mode" has been added to the main BSD Sockets/TCP/UDP tests: TCP_STREAM, TCP_MAERTS, TCP_SENDFILE, TCP_RR, TCP_CC, TCP_CRR and UDP_RR. It has not been added to UDP_STREAM. This mode is enabled with --enable-demo when configuring netperf, which activates a global "-D" option. By default, -D will cause interim results (throughput or transactions/s only, not CPU util) from the netperf's perspective to be emitted no sooner than once per second. An optional parameter can specify another interval in units (floating point) of seconds: -D 1.5 will make the reporting interval at least 1.5 seconds. This mode makes no use of explicit interval timers since that can be so, well fun on different platforms. Instead, an initial guess of how many units of work must be done to consume the desired reporting interval is made, and that guess is refined throughout the entire test. If something happens to dramatically slow-down the test, the reproting interval may become must larger for a few intervals. When things speed-up it is detected very quickly. As with the --enable-historgram support, if gethrtime() is available on the platform, it will be used in lieu of gettimeofday(). In any case, the number of calls to gettimeofday()/gethrtime() is much, Much, MUCH smaller than for --enable-histogram so while there may be a measurable effect on the results, it should be rather small. *) The global -H option has been enhanced to take an optional address family specification for the control connection: -H , Unlike other comma-separated options, where specifying only one thing will set both, here specifying only one thing will be ass-u-me-d to be the and will leave defaulted (AF_UNSPEC). Family can be specified as "4" or "inet" for AF_INET, "6" or "inet6" for AF_INET6. *) A new global -L option has been added to specify the local name/IP and/or address family for the control connection: -L , Unlike other comma-separated options, where specifying only one thing will set both, here specifying only one thing will be ass-u-me-d to be the and will leave defaulted (AF_UNSPEC). Family can be specified as "4" or "inet" for AF_INET, "6" or "inet6" for AF_INET6. *) Test-specific -H and -L options are present for the TCP, UDP and SCTP tests, which are now (intended to be) IP protocol version agnostic. *) Global -4 and -6 options will set the both the local and remote address family to either AF_INET or AF_INET6 respectively. *) Test-specific -4 and -6 options have been added for TCP, UDP and SCTP tests. *) Since the basic TCP UDP and SCTP tests are no longer IPv4-only, the nettest_ipv6.[ch] files are only included in the source distribution for historical interest. *) The main test banners for the TCP, UDP and SCTP tests have been enhanced to give both local and remote addressing information for the data connection. *) Compilation under Windows is likely FUBAR at this point. I _hope_ to start trying to do builds under the DDK soon, but am not sure when I'll be able to start. Any and all assistance you can give there would be most welcome. *) Various and sundry fixes. TCP_RR should no longer go into an infinite loop when you abort netperf. I'm sure there are others. *) Unix domain socket tests are compiled-in with --enable-unix=yes at configure time. *) DLPI tests are compiled-in with --enable-dlpi=yes at configure time. *) XTI tests are compiled-in with --enable-xti=yes at configure time. Things not changed in this release: *) Seems like everything has changed :) These are the Release Notes for Revision 2.3pl2 of netperf: Things changed in this release *) One can bind netperf or netserver to specific CPUs with the -T option. This is a generalization of some HP-UX and netserver specific work from 2.3pl1. *) Extend the kludge to workaround the Linux setsockopt/getsockopt bizzarreness to the socket buffer sizes for the remote side in addition to the local side. *) Fix the lack of initialization of times_up in recv_tcp_maerts() that caused confidence intervals to fail miserably. *) Other misc fixes - than you to all of you who sent them. These are the Release Notes for revision 2.3pl1 of netperf: Things changed in this release *) The bind() call in create_data_socket() in the file nettest_bsd.c is no longer conditional on the user's specifying an IP address or port number to which the data socket should be bound. This fixes the "connection refused" errors in the UDP tests. *) Some experimental code to allow one to specify a CPU to which the remote netserver should be bound. This is intended to allow one to get greater certainty (as in confidence intervals) on SMP systems. At present the functionality is HP-UX specific. Submittals of changes for a more general approach are welcomed. These are the Release Notes for revision 2.3 of netperf: Things changed in this release *) The user can now specify local and/or remote port numbers for the data connection using the -P test-specific option. This is to support those folks who want to run netperf through those evil, end-to-end-breaking things known as firewalls... :) This changes the format of some of the control messages, hence the bump in the update number in the VUF. While it may be possible to mix 2.3 and pre-2.3 netperf and netserver, it is not supported. *) The user can now specify local and/or remote IP addresses for the data connection using the -I test-specific option. This is to support those folks who want to run netperf through those evil, end-to-end-breaking things known as firewalls... :) This changes the format of some of the control messages, hence the bump in the update number in the VUF. While it may be possible to mix 2.3 and pre-2.3 netperf and netserver, it is not supported. *) Set DL_mumble message priorities in the DLPI tests *) Fix error return check for getaddrinfo() *) Those systems with gethrtime() can define -DHAVE_GETHRTIME to use gethrtime() instead of gettimeofday() and reduce the measurement overhead when enabling the -DHISTOGRAM functionality. *) The default for -DHISTOGRAM compilation now adds a UNIT_USEC and TEN_USEC row and renames TENTH_MSEC to HUNDRED_USEC. If you want the old behaviour add -DOLD_HISTOGRAM to CFLAGS. *) Add missing '!' in the recv_udp*_stream so we recognize the end of a timed test correctly. *) Replace "||" with "&&" to fix an infinite loop in recv_tcp_conn_rr() most likely introduced in 2.2pl5. *) Code has been added to kludge around the bug in Linux getsockopt() where it almost always returns twice the value for which one asks unlike virtually every other stack on the face of the planet. This was doing some unpleasant things to tests in which confidence intervals were requested. Things not changed in this release *) Lots :) These are the Release Notes for revision 2.2pl5 of netperf: Things changed in this release *) Improved (perhaps even usable :) support for Windows, including compilation and run on Win64. *) Fixes for MacOS X and FreeBSD Things not changed in this release *) Specifying the port number(s) for the data connection These are the Release Notes for Revision 2.2pl4 of netperf: Things changed in this release *) USE_SYSCTL available on suitable FreeBSD releases to measure CPU utilization without having to resort to -DUSE_LOOPER. *) Include Solaris 9 with the Linux sendfile path under -DHAVE_SENDFILE This still outstanding in this release *) Knowing why signals are not interrupting socket calls under OpenVMS. A quick try to use threads for timing a la Win32 worked, but also cut performance in half. Any and all assistance in this area would be most welcome. These are the Release Notes for revisoin 2.2pl3 of netperf: Things changed in this release *) I started practicing what I preach and will set SO_REUSEADDR before netserver tries to bind to its well-known port. *) Initial port to OpenVMS. This includes support for the OVMS Auxilliary server (inetd replacement). See README.ovms for more details on what is involved in compiling and running netperf under OpenVMS. *) Testname comparisons are now case insensitive. This is a side effect of OpenVMS downshifting commandlines to lowercase. I made the change and decided it was OK to keep it that way, even though for OpenVMS one _has_ to set the right defines to disable that downshifting or the command-line options will not work. For example "-H" will become "-h" which isn't quite the same thing... *) Misc fixes for nettest_ipv6.c. *) Support for sendfile() under Linux Thins I would like to have changed but did not know how or didn't have time: *) Allow netserver to run as a standalone daemon under OpenVMS *) Allow netserver to run as a standalone daemon under Windows *) Rediscover an inetd-like facility for Windows *) Figure-out how to get low-overhead, accurate, per-CPU utilization figures under OpenVMS *) Get the UDP_RR and UDP_STREAM tests to work under OpenVMS, and get the TCP_RR test to work based on time rather than transaction count. There is some bug (possibly in OpenVMS?) where the SIGALRM fires, but a socket call will not return an EINTR. Things that changed prior to this release: *) Addition of the TCP_MAERTS test - this is a TCP_STREAM test where the data flows from the netserver to the netperf rather than from the netperf to the netserver. This can be useful in those situations where netperf (netserver) is installed on a remote system, but the tester has no shell access and wishes to get performance data for the path from netserver to netperf. These are the Release Notes for the 2.2 revision of netperf: Things changed in this release *) Various and sundry bugs fixed (in theory) for platforms such as FreeBSD and Linux. If I left-out your bug fix, it was purely accidental - my mind has a very small cache, and sometimes I will "lose" email in the shuffle. *) Initial support for sendfile() on HP-UX. This test will use the sendfile() call instead of send() to send data to the remote. Netperf "lies" to netserver and calls it a TCP_STREAM test since what netserver needs to do is exactly the same. A future patch may change that and simply have netserver call the same routine for both test types. Kudos to Charles Harris for the initial prototype. *) The Fore ATM API and HiPPI tests have been dropped from the distribution. Things I would have liked to have changed, but did not have time for: *) Conversion of the source and makefile to use the GNU configure/autoconf utility to make it easier for folks to build by not having to edit makefiles... You will notice that I have started to switch from "DO_MUMBLE" to "HAVE_MUMBLE" as always - happy benchmarking, rick jones --------------------------------------------------------------------- These are the Release Notes for the 2.1pl3 revision of netperf: *) An OBOB (Off By One Bug) in netlib.c that was causing a core dump on Irix should be fixed. *) Irix systems should now be able to determine the number of CPU's present automagically (code from outside, not tested yet because I have no MP Irix systems at my disposal) *) An alpha version of a TCP_CC test has been added - this is a TCP_CRR test with out the "RR." *) The -Ae has been removed from the default makefile. If someone has a nice way to automagically generate the correct makefile for different platforms I would like to learn how. happy benchmarking, rick jones ---------------------------------------------------------------------- These are the Release Notes for the 2.1 revision of netperf: Things Changed in this release: *) The XTI (Version 2 of the spec) tests are now documented in the manual. *) The TCP_CRR (Connect Request/Response) test is now documented in the manual, including a description of how it mimics the behaviour of http (the protocol underlying the WWW). *) Support for for Windows NT 3.51 OS in the BSD Sockets tests (ok, so they are really Winsock in that case :). Other test suites may be ported as required/desired/appropriate. *) Tests for TCP and UDP, using the IPv6 extensions to BSD sockets are included in this release. They are included by adding -DUSE_IPv6 to the makefile and recompiling. *) Support for a "long long" datatype should only be required for -DUSE_PSTAT compilation which is an HP-UX only thing. The *unbundled* HP compilers from at least "HP92453-01 A.09.61 HP C Compiler" and later should have the required support. The bundled compiler may not. GCC should work - check the archives listed in the comp.sys.hp.hpux FAQ for copies. The FAQ is archived on rtfm.mit.edu under the path pub/usenet/comp.sys.hp.hpux. *) A "proper" fix for double data type alignment has been included. *) A new script is included with this release which can be used to measure aggregate TCP_RR performance (multiple, concurrent instances of the TCP_RR test). A related use of this script would be measuring MP scaling. A single-byte TCP_RR test is good for this purpose for two reasons: 1) it excercises the control/protocol paths heavily without using much in the way of data copies which may be easier to scale. 2) most systems can easily saturate cards with bandwidth, but not so easily with request/response Of course, feedback on this is most welcome. *) When measuring CPU utilization, the units for service demand have been changed from milliseconds (designated ms) of CPU per unit (KB or Transaction) to microseconds (desginated us). *) For accurate reporting of service demand, netperf needs to know the number of CPU's present on a system. On some systems (HP-UX), this is automatic. For others (All), it is necessary to add a global "-n " option to both netperf and netserver. !! IF THIS IS LEFT-OUT CPU UTILIZATION AND SERVICE DEMAND FOR !! !! MULTI-PROCESSOR SYSTEMS WILL BE WRONG. !! If you know of ways to programatically determine the number of active CPUs on a system, please let the author Rick Jones know. *) other things I've probably forgotten :) Things Not Changed in this release: *) The ancillary test suites are essentially unchanged - DLPI, HiPPI/LLA, Unix Domain, and Fore ATM API. Unless there is much interest expressed in these tests, 2.1 may be the last release in which they are included. The order of retirement would likely be Unix Domain, HiPPI/LLA, Fore ATM API, and then DLPI. Miscelaneous Comments: *) The -DUSE_LOOPER CPU utilization _seems_ to be nice and low-impact on HP-UX, Digital Unix, and IRIX. It does not yet seem to be low-impact on Solaris (I need an example of priocntl usage), AIX (setpri only works if you are root), and NT (not sure of the reason). Help with those problems would be most appreciated. 0707010003bba0000081a40000000000000000000000014f45c4ce0000081f000000b500010002ffffffffffffffff0000002900000000root/usr/local/share/doc/netperf/COPYING Copyright (C) 1993 Hewlett-Packard Company ALL RIGHTS RESERVED. The enclosed software and documentation includes copyrighted works of Hewlett-Packard Co. For as long as you comply with the following limitations, you are hereby authorized to (i) use, reproduce, and modify the software and documentation, and to (ii) distribute the software and documentation, including modifications, for non-commercial purposes only. 1. The enclosed software and documentation is made available at no charge in order to advance the general development of high-performance networking products. 2. You may not delete any copyright notices contained in the software or documentation. All hard copies, and copies in source code or object code form, of the software or documentation (including modifications) must contain at least one of the copyright notices. 3. The enclosed software and documentation has not been subjected to testing and quality control and is not a Hewlett-Packard Co. product. At a future time, Hewlett-Packard Co. may or may not offer a version of the software and documentation as a product. 4. THE SOFTWARE AND DOCUMENTATION IS PROVIDED "AS IS". HEWLETT-PACKARD COMPANY DOES NOT WARRANT THAT THE USE, REPRODUCTION, MODIFICATION OR DISTRIBUTION OF THE SOFTWARE OR DOCUMENTATION WILL NOT INFRINGE A THIRD PARTY'S INTELLECTUAL PROPERTY RIGHTS. HP DOES NOT WARRANT THAT THE SOFTWARE OR DOCUMENTATION IS ERROR FREE. HP DISCLAIMS ALL WARRANTIES, EXPRESS AND IMPLIED, WITH REGARD TO THE SOFTWARE AND THE DOCUMENTATION. HP SPECIFICALLY DISCLAIMS ALL WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. 5. HEWLETT-PACKARD COMPANY WILL NOT IN ANY EVENT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES (INCLUDING LOST PROFITS) RELATED TO ANY USE, REPRODUCTION, MODIFICATION, OR DISTRIBUTION OF THE SOFTWARE OR DOCUMENTATION. 0707010003bba1000081a40000000000000000000000014f45c4ce0000001b000000b500010002ffffffffffffffff0000002b00000000root/usr/local/share/doc/netperf/ChangeLogSee the file Release_Notes.0707010003bb9f000081a40000000000000000000000014f45c4ce00001c38000000b500010002ffffffffffffffff0000002900000000root/usr/local/share/doc/netperf/AUTHORSThis file is here for people to list their contributions to the netperf benchmark. When you enhance or fix something, put your name and a description of the what/where/whey/why/how here. If you like, feel free to include an email address. I would like to apologize in advance to anyone I've forgotten to include. Rick Jones Responsible for initial packaging and release of netperf and "editorial" continuity for subsequent releases. Karen Choy Code to allow netserver to run as a standalone daemon. Dave Shield Wrote the first revision of the netperf and netserver manpages. Sarr Blumson Fixes for AIX 3.1 and 3.2. Also fixes for Solaris 2.1 without realizing it ;-) Jeff Smits Fixes for TCP_RR and UDP_RR on sytems with an htonl that is not a no-op. Warren Burnett Example code for DLPI tests. Several Folks Code to tell SunOS 4 to *not* restart system calls on receipt of a signal. Fore Systems Inc. Manpages for the FORE API and question answering David Channin Access to systems running the Fore ATM API Jonathan Stone Include file fixes for Ultrix Bruce Barnett Bunches of warnings fixes and lint picks for Solaris 2.3 Herman Dierks et al Code to calculate confidence intervals for tests Hal Murray Helpful suggestions for the scripts to make them more compatible with the netperf database (http://www.cup.hp.com/netperf/NetperfPage.html). His prompting finally got me off my whatever to put the confidence interval stuff from the guys at IBM into netperf Peter Skopp pds@cs.columbia.edu Fixes to make netperf more secure. Tom Wilson A fix to send_udp_rr to correct bogus throughput values. Thorsten Lockert A bunch of clean-up for the *BSD OSes Serge Pachkovsky Code for low-priority soaker process for AIX and SGI The fine folks at Adaptec The initial port of netperf (1.9PL4) to Windows NT 3.51. Robin Callender The PPC binaries for the 1.9PL4 port of netperf to NT and for assorted code clean-ups and help with CPU utilization measurements. "Todd J. Derr" For offering to take-on support of the Fore ATM API files with 2.1 and for his help in making the tar files and such more user-friendly Michael Shuldman Improvements to the makefile and additional checks for OpenBSD Kris Corwin discovery of a debug statement outside of if (debug) that may have been the cause of all the nasty connection refused errors in random UDP_RR tests... Charles Harris Initial prototype of the TCP_SENDFILE test support Philip Pishioneri of Cornel Conversion of the netperf.ps manul to PDF format. The Hewlett-Packard OpenVMS folks Assistance with the port to OpenVMS Munechika SUMIKAWA @ KAME Project / FreeBSD.org IPv6 fixes Jan Iven of CERN initial mods for sendfile() under Linux Fabrice Bacchella for pointing-out that Solaris 9 has a copy of Linux sendfile() Andrew Gallatin for assistance with the FreeBSD sysctl() stuff, and later making it calibration-free fixes to configure to recognize Solaris 11 fixes to netcpu_procstat.c for later linux kernels workarounds to get Linux to report ENOBUFS on TX queue overflows Mark Cooper pointing-out the need for -lresolv when compiling -DDO_DNS on RedHat 7.1 Carl Mascott finding some cut-and-paste erors in create_data_socket error logging Fabrice Bacchella Fixes for -DHISTOGRAM and -DUNIX on Mac OS X, updates to usage strings Spencer Frink Fixes and Cleanup for WIN32. Many over many years. Nicholas Thomas Fixes for DLPI on SVR4 Streams under Linux Dave Craig Fixes for getaddrinfo error returns David Mosberger of HP Workaround for the Linux getsockopt() bug that returns more than that for which one asked. Stephen Burger of HP Code to implement the netserver CPU binding. Vladislav "Vlad" Yasevich of HP Initial SCTP tests. Enhancements to the configure.ac sources to show the way to make many of the LIBS="foo" before ./configure unnecessary. Padmanabhan "Paddu" S N of HP Patches for /proc/stat CPU util and recv_tcp_rr. Cary Coutant and other hp-mac-users of HP Access to Mac OS X systems for porting netperf 2.4.0 Chris Bertin of HP Access to AIX for initial porting of netperf 2.4.0 James Carlson Assistance finding the right magic to compile SCTP on Solaris 10. Gavin Pointers on Solaris 10 Microstate accounting. Brent Draney Getting netcpu_perfstat.c in running order on AIX and other misc fixups in places such as BSD. Samuel Ying Change struct sockaddr to struct sockaddr storage in netserver.c Rodolpho Boer Fix for default message size in UDP_STREAM when defualt SO_SNDBUF size is > max UDP datagram size. Michael Dorff Getting netperf/netserver to compile under Windows with MS Visual Studio 2003 George Davis Changes to deal with different floating-point formats. Anonymous Changes to retrieve CPU util on MacOS X. Dickon Reed Patches to attend to some windows in TCP_CRR and TCP_CC under Windows Bret McKee Fixes to get netcpu_looper compiling and working after the "netcpu" split Hans Blom Improvements to closing/redirecting stdin/stdout/stderr in netserver Martin Brown RPM support in the form of netperf.spec.in and related configure.ac etc changes Shilpi Agarwal Changes to allow UDP_STREAM to use connected sockets on both sides. Steve Reinhardt Fixes for buffer filling. Gisle Vanem Fixes for Windows compilation under MingW/gcc. Scott Weitzenkamp Patches to enable demo mode in the UDP_STREAM test Emir Halepovic Feedback on the manual Kouhei Sutou Generate netperf_version.h and netperf.spec via configure rather than makefile, include limits to get PathMAX on FreeBSD. Dan Yost Fix to fflush() each interim result in demo mode to make things happier for folks redirecting same to a file. Alexander Duyck Fixes to replace struct sockaddr_in with struct sockaddr_storage Fixes to UDP_RR to preclude hangs on Windows Fizes to UDP_RR to honour -f and -B options Anonymous Support for sendfile() on OSX Matt Waddel Fix to use vfork() instead of fork() on platforms without fork() Simon Burge Fixes for *BSD CPU util. Adam Bidema Fixes for launching netserver children when the path to netserver.exe is very long. Gisle Vanem MingW cnd MSDOS (djgpp) cleanups. Marcel Shuldman Changes to make netperf more profiling friendly Bruno Cornec Fixes to supply some missing fprintf format statements. Jose Pedro Oliveira Linux compilation fixes when SCTP and DCCP are enabled. Changes to configure.ac to allow it to inherit compiler flags from environment variables. Pal Baranyai Typo in nettest_dlpi.c Brian Haley Changes to allow something like netperf -H ::1 to work Frank Schuster Discovering that FreeBSD 8.X also does not need an SCTP library Josselin Costanzi DEBUG_LOG_FILE patch for Android Dongsheng Song Assorted Windows fixes Hushan Jia Fix to actually run SCTP_RR_MANY when requested David MacMahon davidm@astro.berkeley.edu Fix to allow configure in a build directory.0707010003bba6000041ed0000000000000000000000034f45c9f100000000000000b500010002ffffffffffffffff0000001900000000root/usr/local/share/man0707010003bba7000041ed0000000000000000000000024f45c9f100000000000000b500010002ffffffffffffffff0000001e00000000root/usr/local/share/man/man10707010003bba8000081a40000000000000000000000014f45c14b00001c24000000b500010002ffffffffffffffff0000002800000000root/usr/local/share/man/man1/netperf.1.TH netperf 1 "" .SH NAME netperf \- a network performance benchmark .SH SYNOPSIS .B netperf [global options] -- [test specific options] .SH DESCRIPTION .B Netperf is a benchmark that can be used to measure various aspects of networking performance. Currently, its focus is on bulk data transfer and request/response performance using either TCP or UDP, and the Berkeley Sockets interface. In addition, tests for DLPI, and Unix Domain Sockets, tests for IPv6 may be conditionally compiled-in. .SS GLOBAL OPTIONS .TP .B \-4 Use AF_INET (aka IPv4) addressing for the control and possibly data connections. .TP .B \-6 Use AF_INET6 (aka IPv6) addressing for the control and possibly data connections. .TP .B \-a sizespec Alter the send and receive buffer alignments on the local system. This defaults to 8 bytes. .TP .B \-A sizespec As -a, but for the remote system. .TP .B \-B brandstr Add brandstr to the output of a test with banners disabled. .TP .B \-c [rate] Request CPU utilization and service demand calculations for the local system. If the optional rate parameter is specified, .B netperf will use that instead of calculating the rate itself. .TP .B \-C [rate] As -c, but for the remote system. .TP .B \-d Increase the quantity of debugging output displayed during a test (possibly at the expense of performance). .TP .B \-D [secs,units] (*) Display interim results at least every secs seconds uning units as the initial guess for units per second. This is only available when netperf has been configured with --enable-demo. .TP .B \-f GMKgmk Change the units of measure for *_STREAM tests. Capital letters are powers of two, lowercase are powers of ten. .TP .B \-F fill_file Pre-fill the send buffers with data from the named file. This is intended to provide a means for avoiding buffers that are filled with data which is trivially easy to compress. A good choice for a file that should be present on any system is this manpage - netperf.man. Other files may be provided as part of the distribution. .TP .B \-h Display a usage string, and exit. .TP .B \-H name|ip,family (*) Set the hostname (or IP address) and address family to use to establish the control connection to the remote system. Passing a single name with no comma will only set remote_host and will leave selection of address family for the control connection to the stack or by a -4 -r -6 command line option. .TP .B \-i max,min Set the maximum and minimum number of iterations when trying to reach certain confidence levels. .TP .B \-j Instruct netperf to calculate additional statistics on timing when running an omni test. Display of said statistics will depend on the presence of the corresponding output selectors in the output selection. These are MIN_LATENCY, MAX_LATENCY, P50_LATENCY, P90_LATENCY, P99_LATENCY, MEAN_LATENCY and STDDEV_LATENCY. .TP .B \-I lvl,[,intvl] Specify the confidence level (either 95 or 99 - 99 is the default) and the width of the confidence interval as a percentage (default 10) .TP .B \-l testlen Specify the length of the test (default 10 seconds). A negative value sets the number of request/response transactions, or the number of bytes for a stream test. .TP .B \-L name|ip,fam (*) Set the local name|IP and/or address family for the socket used for the control connection to the remote netserver. .TP .B \-n numcpus Specify the number of CPU's in the system on those systems for which netperf has no way to find the number of CPU's programatically. .TP .B \-N This option will tell netperf to not establish a control connection to a remote netserver. Instead it will try to establish a data connection directly, using only the information supplied by the command line parameters and/or internal defaults. Unless other ports are provided by the command line, by default the data connection will be to the "discard" port for a "STREAM" or "SENDFILE" test, the "echo" port for an "RR" test or the "chargen" port for a "MAERTS" test. .TP .B \-o sizespec Set an offset from the alignment specified with -a. .TP .B \-O sizespec As -o, but for the remote system. .TP .B \-p portnum,locport (*) Direct the control connection to a netserver listening on the specified port, rather than using a "netperf" entry in /etc/services or the internal default (port 12865). If ",locport" is specified the control connection will be established from that local port number. Specifying a single port number with no comma will specify only the remote netserver port number and will leave local port number selection to the stack. .TP .B \-P 0|1 Show (1) or suppress (0) the test banner. .TP .B \-S This option will cause an attempt to set SO_KEEPALIVE on the ends of the data connection for tests using BSD Sockets. It will be made on the netperf side of classic tests, and both netperf and netserver side of an omni or migrated test. .TP .B \-s seconds This will cause netperf to sleep "seconds" seconds before transferring data over the data connection. .TP .B \-t testname Specify the test to perform. Valid testnames include, but are not limited to, nor always compiled-in: .RS .RS .nf .I TCP_STREAM .I TCP_SENDFILE .I TCP_MAERTS .I TCP_RR .I TCP_CRR .I UDP_STREAM .I UDP_RR .I DLCO_STREAM .I DLCO_RR .I DLCL_STREAM .I DLCL_RR .I STREAM_STREAM .I STREAM_RR .I DG_STREAM .I DG_RR .I SCTP_STREAM .I SCTP_STREAM_MANY .I SCTP_RR .I SCTP_RR_MANY .I LOC_CPU .I REM_CPU .fi .RE .RE .TP .B \-T lcpu,remcpu Request that netperf be bound to CPU lcpu and/or netserver be bound to CPU rcpu. .TP .B \-v verbosity Set the verbosity level for the test (only with -P). .TP .B \-V Display the netperf version and exit. .SS TEST SPECIFIC OPTIONS .TP .B \-h Display a usage string based on the test name set with -t, and exit. Please consult the netperf manual .I Care and Feeding of Netperf 2.5.X (doc/netperf.[pdf|html|txt]) for more information. Or you can join and send email to netperf-talk@netperf.org. .SH NOTE For those options taking two parms, at least one must be specified; specifying one value without a comma will set both parms to that value, specifying a value with a leading comma will set just the second parm, a value with a trailing comma will set just the first. To set each parm to unique values, specify both and separate them with a comma. * For these options taking two parms, specifying one value with no comma will only set the first parm and will leave the second at the default value. To set the second value it must be preceded with a comma or be a comma-separated pair. This is to retain previous netperf behaviour. .SH BUGS There are bound to be bugs. If you think you have found a bug, please mention it in netperf-talk@netperf.org. List membership is required to send email to the list. See http://www.netperf.org/cgi-bin/mailman/listinfo/netperf-talk . If all else fails send email to netperf-feedback@netperf.org. .SH SEE ALSO .BR netserver (1) .br .I Care and Feeding of Netperf 2.5.X .br http://www.netperf.org/ .SH AUTHORS HP Information Networks Division - Networking Performance Team. .br Rick Jones .br Karen Choy HP IND .br Dave Shield (man pages) .br Others too numerous to mention here - see the AUTHORS file 0707010003bba9000081a40000000000000000000000014f45c14b00000651000000b500010002ffffffffffffffff0000002a00000000root/usr/local/share/man/man1/netserver.1.TH netserver 1 "" .SH NAME netserver \- a network performance benchmark server .SH SYNOPSIS .B netserver [-4] [-6] [-d] [-h] [-L name,family] [-p portnum] [-v verbosity] [-V] .SH DESCRIPTION .B Netserver listens for connections from a .C netperf benchmark, and responds accordingly. It can either be run from .C inetd or as a standalone daemon (with the -p flag). If run from .C inetd the -p option should not be used. .SS OPTIONS .TP .B \-4 Use AF_INET (aka IPv4) addressing for the control and possibly data connections. .TP .B \-6 Use AF_INET6 (aka IPv6) addressing for the control and possibly data connections. .TP .B \-d Increase the quantity of debugging output displayed during a test (possibly at the expense of performance). .TP .B \-h Display a usage string, and exit. .TP .B \-L name,family Set the local name and/or address family for the socket used for the control connection. .TP .B \-p portnum Listen on the specified port. This is used when running as a standalone daemon. .TP .B \-v verbosity Set the verbosity level for the test. .TP .B \-V Display the netperf version and exit. .SH BUGS No known bugs at this time. If you think you have found a bug, please report it to either netperf-talk@netperf.org or netperf-feedback@netperf.org. .SH SEE ALSO .BR netperf (1) .br .I Netperf: A Network Performance Benchmark .br http://www.netperf.org/ .SH AUTHORS HP Information Networks Division - Networking Performance Team. .br Rick Jones .br Karen Choy HP IND .br Dave Shield (man pages) .br Others too numerous to mention here - see the AUTHORS file 0707010003bba4000041ed0000000000000000000000024f45c9f100000000000000b500010002ffffffffffffffff0000001a00000000root/usr/local/share/info0707010003bba5000081a40000000000000000000000014f45c14a0002d501000000b500010002ffffffffffffffff0000002700000000root/usr/local/share/info/netperf.infoThis is netperf.info, produced by makeinfo version 4.13 from netperf.texi. This is Rick Jones' feeble attempt at a Texinfo-based manual for the netperf benchmark. Copyright (C) 2005-2011 Hewlett-Packard Company Permission is granted to copy, distribute and/or modify this document per the terms of the netperf source licence, a copy of which can be found in the file `COPYING' of the basic netperf distribution.  File: netperf.info, Node: Top, Next: Introduction, Prev: (dir), Up: (dir) Netperf Manual ************** This is Rick Jones' feeble attempt at a Texinfo-based manual for the netperf benchmark. Copyright (C) 2005-2011 Hewlett-Packard Company Permission is granted to copy, distribute and/or modify this document per the terms of the netperf source licence, a copy of which can be found in the file `COPYING' of the basic netperf distribution. * Menu: * Introduction:: An introduction to netperf - what it is and what it is not. * Installing Netperf:: How to go about installing netperf. * The Design of Netperf:: * Global Command-line Options:: * Using Netperf to Measure Bulk Data Transfer:: * Using Netperf to Measure Request/Response :: * Using Netperf to Measure Aggregate Performance:: * Using Netperf to Measure Bidirectional Transfer:: * The Omni Tests:: * Other Netperf Tests:: * Address Resolution:: * Enhancing Netperf:: * Netperf4:: * Concept Index:: * Option Index::  File: netperf.info, Node: Introduction, Next: Installing Netperf, Prev: Top, Up: Top 1 Introduction ************** Netperf is a benchmark that can be use to measure various aspect of networking performance. The primary foci are bulk (aka unidirectional) data transfer and request/response performance using either TCP or UDP and the Berkeley Sockets interface. As of this writing, the tests available either unconditionally or conditionally include: * TCP and UDP unidirectional transfer and request/response over IPv4 and IPv6 using the Sockets interface. * TCP and UDP unidirectional transfer and request/response over IPv4 using the XTI interface. * Link-level unidirectional transfer and request/response using the DLPI interface. * Unix domain sockets * SCTP unidirectional transfer and request/response over IPv4 and IPv6 using the sockets interface. While not every revision of netperf will work on every platform listed, the intention is that at least some version of netperf will work on the following platforms: * Unix - at least all the major variants. * Linux * Windows * Others Netperf is maintained and informally supported primarily by Rick Jones, who can perhaps be best described as Netperf Contributing Editor. Non-trivial and very appreciated assistance comes from others in the network performance community, who are too numerous to mention here. While it is often used by them, netperf is NOT supported via any of the formal Hewlett-Packard support channels. You should feel free to make enhancements and modifications to netperf to suit your nefarious porpoises, so long as you stay within the guidelines of the netperf copyright. If you feel so inclined, you can send your changes to netperf-feedback for possible inclusion into subsequent versions of netperf. It is the Contributing Editor's belief that the netperf license walks like open source and talks like open source. However, the license was never submitted for "certification" as an open source license. If you would prefer to make contributions to a networking benchmark using a certified open source license, please consider netperf4, which is distributed under the terms of the GPLv2. The netperf-talk mailing list is available to discuss the care and feeding of netperf with others who share your interest in network performance benchmarking. The netperf-talk mailing list is a closed list (to deal with spam) and you must first subscribe by sending email to netperf-talk-request . * Menu: * Conventions::  File: netperf.info, Node: Conventions, Prev: Introduction, Up: Introduction 1.1 Conventions =============== A "sizespec" is a one or two item, comma-separated list used as an argument to a command-line option that can set one or two, related netperf parameters. If you wish to set both parameters to separate values, items should be separated by a comma: parameter1,parameter2 If you wish to set the first parameter without altering the value of the second from its default, you should follow the first item with a comma: parameter1, Likewise, precede the item with a comma if you wish to set only the second parameter: ,parameter2 An item with no commas: parameter1and2 will set both parameters to the same value. This last mode is one of the most frequently used. There is another variant of the comma-separated, two-item list called a "optionspec" which is like a sizespec with the exception that a single item with no comma: parameter1 will only set the value of the first parameter and will leave the second parameter at its default value. Netperf has two types of command-line options. The first are global command line options. They are essentially any option not tied to a particular test or group of tests. An example of a global command-line option is the one which sets the test type - `-t'. The second type of options are test-specific options. These are options which are only applicable to a particular test or set of tests. An example of a test-specific option would be the send socket buffer size for a TCP_STREAM test. Global command-line options are specified first with test-specific options following after a `--' as in: netperf --  File: netperf.info, Node: Installing Netperf, Next: The Design of Netperf, Prev: Introduction, Up: Top 2 Installing Netperf ******************** Netperf's primary form of distribution is source code. This allows installation on systems other than those to which the authors have ready access and thus the ability to create binaries. There are two styles of netperf installation. The first runs the netperf server program - netserver - as a child of inetd. This requires the installer to have sufficient privileges to edit the files `/etc/services' and `/etc/inetd.conf' or their platform-specific equivalents. The second style is to run netserver as a standalone daemon. This second method does not require edit privileges on `/etc/services' and `/etc/inetd.conf' but does mean you must remember to run the netserver program explicitly after every system reboot. This manual assumes that those wishing to measure networking performance already know how to use anonymous FTP and/or a web browser. It is also expected that you have at least a passing familiarity with the networking protocols and interfaces involved. In all honesty, if you do not have such familiarity, likely as not you have some experience to gain before attempting network performance measurements. The excellent texts by authors such as Stevens, Fenner and Rudoff and/or Stallings would be good starting points. There are likely other excellent sources out there as well. * Menu: * Getting Netperf Bits:: * Installing Netperf Bits:: * Verifying Installation::  File: netperf.info, Node: Getting Netperf Bits, Next: Installing Netperf Bits, Prev: Installing Netperf, Up: Installing Netperf 2.1 Getting Netperf Bits ======================== Gzipped tar files of netperf sources can be retrieved via anonymous FTP (ftp://ftp.netperf.org/netperf) for "released" versions of the bits. Pre-release versions of the bits can be retrieved via anonymous FTP from the experimental (ftp://ftp.netperf.org/netperf/experimental) subdirectory. For convenience and ease of remembering, a link to the download site is provided via the NetperfPage (http://www.netperf.org/) The bits corresponding to each discrete release of netperf are tagged (http://www.netperf.org/svn/netperf2/tags) for retrieval via subversion. For example, there is a tag for the first version corresponding to this version of the manual - netperf 2.5.0 (http://www.netperf.org/svn/netperf2/tags/netperf-2.5.0). Those wishing to be on the bleeding edge of netperf development can use subversion to grab the top of trunk (http://www.netperf.org/svn/netperf2/trunk). When fixing bugs or making enhancements, patches against the top-of-trunk are preferred. There are likely other places around the Internet from which one can download netperf bits. These may be simple mirrors of the main netperf site, or they may be local variants on netperf. As with anything one downloads from the Internet, take care to make sure it is what you really wanted and isn't some malicious Trojan or whatnot. Caveat downloader. As a general rule, binaries of netperf and netserver are not distributed from ftp.netperf.org. From time to time a kind soul or souls has packaged netperf as a Debian package available via the apt-get mechanism or as an RPM. I would be most interested in learning how to enhance the makefiles to make that easier for people.  File: netperf.info, Node: Installing Netperf Bits, Next: Verifying Installation, Prev: Getting Netperf Bits, Up: Installing Netperf 2.2 Installing Netperf ====================== Once you have downloaded the tar file of netperf sources onto your system(s), it is necessary to unpack the tar file, cd to the netperf directory, run configure and then make. Most of the time it should be sufficient to just: gzcat netperf-.tar.gz | tar xf - cd netperf- ./configure make make install Most of the "usual" configure script options should be present dealing with where to install binaries and whatnot. ./configure --help should list all of those and more. You may find the `--prefix' option helpful in deciding where the binaries and such will be put during the `make install'. If the netperf configure script does not know how to automagically detect which CPU utilization mechanism to use on your platform you may want to add a `--enable-cpuutil=mumble' option to the configure command. If you have knowledge and/or experience to contribute to that area, feel free to contact . Similarly, if you want tests using the XTI interface, Unix Domain Sockets, DLPI or SCTP it will be necessary to add one or more `--enable-[xti|unixdomain|dlpi|sctp]=yes' options to the configure command. As of this writing, the configure script will not include those tests automagically. Starting with version 2.5.0, netperf is migrating most of the "classic" netperf tests found in `src/nettest_bsd.c' to the so-called "omni" tests (aka "two routines to run them all") found in `src/nettest_omni.c'. This migration enables a number of new features such as greater control over what output is included, and new things to output. The "omni" test is enabled by default in 2.5.0 and a number of the classic tests are migrated - you can tell if a test has been migrated from the presence of `MIGRATED' in the test banner. If you encounter problems with either the omni or migrated tests, please first attempt to obtain resolution via or . If that is unsuccessful, you can add a `--enable-omni=no' to the configure command and the omni tests will not be compiled-in and the classic tests will not be migrated. Starting with version 2.5.0, netperf will include the "burst mode" functionality in a default compilation of the bits. If you encounter problems with this, please first attempt to obtain help via or . If that is unsuccessful, you can add a `--enable-burst=no' to the configure command and the burst mode functionality will nt be compiled-in. On some platforms, it may be necessary to precede the configure command with a CFLAGS and/or LIBS variable as the netperf configure script is not yet smart enough to set them itself. Whenever possible, these requirements will be found in `README.PLATFORM' files. Expertise and assistance in making that more automagical in the configure script would be most welcome. Other optional configure-time settings include `--enable-intervals=yes' to give netperf the ability to "pace" its _STREAM tests and `--enable-histogram=yes' to have netperf keep a histogram of interesting times. Each of these will have some effect on the measured result. If your system supports `gethrtime()' the effect of the histogram measurement should be minimized but probably still measurable. For example, the histogram of a netperf TCP_RR test will be of the individual transaction times: netperf -t TCP_RR -H lag -v 2 TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to lag.hpl.hp.com (15.4.89.214) port 0 AF_INET : histogram Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 16384 87380 1 1 10.00 3538.82 32768 32768 Alignment Offset Local Remote Local Remote Send Recv Send Recv 8 0 0 0 Histogram of request/response times UNIT_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0 TEN_USEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0 HUNDRED_USEC : 0: 34480: 111: 13: 12: 6: 9: 3: 4: 7 UNIT_MSEC : 0: 60: 50: 51: 44: 44: 72: 119: 100: 101 TEN_MSEC : 0: 105: 0: 0: 0: 0: 0: 0: 0: 0 HUNDRED_MSEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0 UNIT_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0 TEN_SEC : 0: 0: 0: 0: 0: 0: 0: 0: 0: 0 >100_SECS: 0 HIST_TOTAL: 35391 The histogram you see above is basically a base-10 log histogram where we can see that most of the transaction times were on the order of one hundred to one-hundred, ninety-nine microseconds, but they were occasionally as long as ten to nineteen milliseconds The `--enable-demo=yes' configure option will cause code to be included to report interim results during a test run. The rate at which interim results are reported can then be controlled via the global `-D' option. Here is an example of `-D' output: $ src/netperf -D 1.35 -H tardy.hpl.hp.com -f M MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to tardy.hpl.hp.com (15.9.116.144) port 0 AF_INET : demo Interim result: 5.41 MBytes/s over 1.35 seconds ending at 1308789765.848 Interim result: 11.07 MBytes/s over 1.36 seconds ending at 1308789767.206 Interim result: 16.00 MBytes/s over 1.36 seconds ending at 1308789768.566 Interim result: 20.66 MBytes/s over 1.36 seconds ending at 1308789769.922 Interim result: 22.74 MBytes/s over 1.36 seconds ending at 1308789771.285 Interim result: 23.07 MBytes/s over 1.36 seconds ending at 1308789772.647 Interim result: 23.77 MBytes/s over 1.37 seconds ending at 1308789774.016 Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. MBytes/sec 87380 16384 16384 10.06 17.81 Notice how the units of the interim result track that requested by the `-f' option. Also notice that sometimes the interval will be longer than the value specified in the `-D' option. This is normal and stems from how demo mode is implemented not by relying on interval timers or frequent calls to get the current time, but by calculating how many units of work must be performed to take at least the desired interval. Those familiar with this option in earlier versions of netperf will note the addition of the "ending at" text. This is the time as reported by a `gettimeofday()' call (or its emulation) with a `NULL' timezone pointer. This addition is intended to make it easier to insert interim results into an rrdtool (http://oss.oetiker.ch/rrdtool/doc/rrdtool.en.html) Round-Robin Database (RRD). A likely bug-riddled example of doing so can be found in `doc/examples/netperf_interim_to_rrd.sh'. The time is reported out to milliseconds rather than microseconds because that is the most rrdtool understands as of the time of this writing. As of this writing, a `make install' will not actually update the files `/etc/services' and/or `/etc/inetd.conf' or their platform-specific equivalents. It remains necessary to perform that bit of installation magic by hand. Patches to the makefile sources to effect an automagic editing of the necessary files to have netperf installed as a child of inetd would be most welcome. Starting the netserver as a standalone daemon should be as easy as: $ netserver Starting netserver at port 12865 Starting netserver at hostname 0.0.0.0 port 12865 and family 0 Over time the specifics of the messages netserver prints to the screen may change but the gist will remain the same. If the compilation of netperf or netserver happens to fail, feel free to contact or join and ask in . However, it is quite important that you include the actual compilation errors and perhaps even the configure log in your email. Otherwise, it will be that much more difficult for someone to assist you.  File: netperf.info, Node: Verifying Installation, Prev: Installing Netperf Bits, Up: Installing Netperf 2.3 Verifying Installation ========================== Basically, once netperf is installed and netserver is configured as a child of inetd, or launched as a standalone daemon, simply typing: netperf should result in output similar to the following: $ netperf TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost.localdomain (127.0.0.1) port 0 AF_INET Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 16384 16384 10.00 2997.84  File: netperf.info, Node: The Design of Netperf, Next: Global Command-line Options, Prev: Installing Netperf, Up: Top 3 The Design of Netperf *********************** Netperf is designed around a basic client-server model. There are two executables - netperf and netserver. Generally you will only execute the netperf program, with the netserver program being invoked by the remote system's inetd or having been previously started as its own standalone daemon. When you execute netperf it will establish a "control connection" to the remote system. This connection will be used to pass test configuration information and results to and from the remote system. Regardless of the type of test to be run, the control connection will be a TCP connection using BSD sockets. The control connection can use either IPv4 or IPv6. Once the control connection is up and the configuration information has been passed, a separate "data" connection will be opened for the measurement itself using the API's and protocols appropriate for the specified test. When the test is completed, the data connection will be torn-down and results from the netserver will be passed-back via the control connection and combined with netperf's result for display to the user. Netperf places no traffic on the control connection while a test is in progress. Certain TCP options, such as SO_KEEPALIVE, if set as your systems' default, may put packets out on the control connection while a test is in progress. Generally speaking this will have no effect on the results. * Menu: * CPU Utilization::  File: netperf.info, Node: CPU Utilization, Prev: The Design of Netperf, Up: The Design of Netperf 3.1 CPU Utilization =================== CPU utilization is an important, and alas all-too infrequently reported component of networking performance. Unfortunately, it can be one of the most difficult metrics to measure accurately and portably. Netperf will do its level best to report accurate CPU utilization figures, but some combinations of processor, OS and configuration may make that difficult. CPU utilization in netperf is reported as a value between 0 and 100% regardless of the number of CPUs involved. In addition to CPU utilization, netperf will report a metric called a "service demand". The service demand is the normalization of CPU utilization and work performed. For a _STREAM test it is the microseconds of CPU time consumed to transfer on KB (K == 1024) of data. For a _RR test it is the microseconds of CPU time consumed processing a single transaction. For both CPU utilization and service demand, lower is better. Service demand can be particularly useful when trying to gauge the effect of a performance change. It is essentially a measure of efficiency, with smaller values being more efficient and thus "better." Netperf is coded to be able to use one of several, generally platform-specific CPU utilization measurement mechanisms. Single letter codes will be included in the CPU portion of the test banner to indicate which mechanism was used on each of the local (netperf) and remote (netserver) system. As of this writing those codes are: `U' The CPU utilization measurement mechanism was unknown to netperf or netperf/netserver was not compiled to include CPU utilization measurements. The code for the null CPU utilization mechanism can be found in `src/netcpu_none.c'. `I' An HP-UX-specific CPU utilization mechanism whereby the kernel incremented a per-CPU counter by one for each trip through the idle loop. This mechanism was only available on specially-compiled HP-UX kernels prior to HP-UX 10 and is mentioned here only for the sake of historical completeness and perhaps as a suggestion to those who might be altering other operating systems. While rather simple, perhaps even simplistic, this mechanism was quite robust and was not affected by the concerns of statistical methods, or methods attempting to track time in each of user, kernel, interrupt and idle modes which require quite careful accounting. It can be thought-of as the in-kernel version of the looper `L' mechanism without the context switch overhead. This mechanism required calibration. `P' An HP-UX-specific CPU utilization mechanism whereby the kernel keeps-track of time (in the form of CPU cycles) spent in the kernel idle loop (HP-UX 10.0 to 11.31 inclusive), or where the kernel keeps track of time spent in idle, user, kernel and interrupt processing (HP-UX 11.23 and later). The former requires calibration, the latter does not. Values in either case are retrieved via one of the pstat(2) family of calls, hence the use of the letter `P'. The code for these mechanisms is found in `src/netcpu_pstat.c' and `src/netcpu_pstatnew.c' respectively. `K' A Solaris-specific CPU utilization mechanism whereby the kernel keeps track of ticks (eg HZ) spent in the idle loop. This method is statistical and is known to be inaccurate when the interrupt rate is above epsilon as time spent processing interrupts is not subtracted from idle. The value is retrieved via a kstat() call - hence the use of the letter `K'. Since this mechanism uses units of ticks (HZ) the calibration value should invariably match HZ. (Eg 100) The code for this mechanism is implemented in `src/netcpu_kstat.c'. `M' A Solaris-specific mechanism available on Solaris 10 and latter which uses the new microstate accounting mechanisms. There are two, alas, overlapping, mechanisms. The first tracks nanoseconds spent in user, kernel, and idle modes. The second mechanism tracks nanoseconds spent in interrupt. Since the mechanisms overlap, netperf goes through some hand-waving to try to "fix" the problem. Since the accuracy of the handwaving cannot be completely determined, one must presume that while better than the `K' mechanism, this mechanism too is not without issues. The values are retrieved via kstat() calls, but the letter code is set to `M' to distinguish this mechanism from the even less accurate `K' mechanism. The code for this mechanism is implemented in `src/netcpu_kstat10.c'. `L' A mechanism based on "looper"or "soaker" processes which sit in tight loops counting as fast as they possibly can. This mechanism starts a looper process for each known CPU on the system. The effect of processor hyperthreading on the mechanism is not yet known. This mechanism definitely requires calibration. The code for the "looper"mechanism can be found in `src/netcpu_looper.c' `N' A Microsoft Windows-specific mechanism, the code for which can be found in `src/netcpu_ntperf.c'. This mechanism too is based on what appears to be a form of micro-state accounting and requires no calibration. On laptops, or other systems which may dynamically alter the CPU frequency to minimize power consumtion, it has been suggested that this mechanism may become slightly confused, in which case using BIOS/uEFI settings to disable the power saving would be indicated. `S' This mechanism uses `/proc/stat' on Linux to retrieve time (ticks) spent in idle mode. It is thought but not known to be reasonably accurate. The code for this mechanism can be found in `src/netcpu_procstat.c'. `C' A mechanism somewhat similar to `S' but using the sysctl() call on BSD-like Operating systems (*BSD and MacOS X). The code for this mechanism can be found in `src/netcpu_sysctl.c'. `Others' Other mechanisms included in netperf in the past have included using the times() and getrusage() calls. These calls are actually rather poorly suited to the task of measuring CPU overhead for networking as they tend to be process-specific and much network-related processing can happen outside the context of a process, in places where it is not a given it will be charged to the correct, or even a process. They are mentioned here as a warning to anyone seeing those mechanisms used in other networking benchmarks. These mechanisms are not available in netperf 2.4.0 and later. For many platforms, the configure script will chose the best available CPU utilization mechanism. However, some platforms have no particularly good mechanisms. On those platforms, it is probably best to use the "LOOPER" mechanism which is basically some number of processes (as many as there are processors) sitting in tight little loops counting as fast as they can. The rate at which the loopers count when the system is believed to be idle is compared with the rate when the system is running netperf and the ratio is used to compute CPU utilization. In the past, netperf included some mechanisms that only reported CPU time charged to the calling process. Those mechanisms have been removed from netperf versions 2.4.0 and later because they are hopelessly inaccurate. Networking can and often results in CPU time being spent in places - such as interrupt contexts - that do not get charged to a or the correct process. In fact, time spent in the processing of interrupts is a common issue for many CPU utilization mechanisms. In particular, the "PSTAT" mechanism was eventually known to have problems accounting for certain interrupt time prior to HP-UX 11.11 (11iv1). HP-UX 11iv2 and later are known/presumed to be good. The "KSTAT" mechanism is known to have problems on all versions of Solaris up to and including Solaris 10. Even the microstate accounting available via kstat in Solaris 10 has issues, though perhaps not as bad as those of prior versions. The /proc/stat mechanism under Linux is in what the author would consider an "uncertain" category as it appears to be statistical, which may also have issues with time spent processing interrupts. In summary, be sure to "sanity-check" the CPU utilization figures with other mechanisms. However, platform tools such as top, vmstat or mpstat are often based on the same mechanisms used by netperf. * Menu: * CPU Utilization in a Virtual Guest::  File: netperf.info, Node: CPU Utilization in a Virtual Guest, Prev: CPU Utilization, Up: CPU Utilization 3.1.1 CPU Utilization in a Virtual Guest ---------------------------------------- The CPU utilization mechanisms used by netperf are "inline" in that they are run by the same netperf or netserver process as is running the test itself. This works just fine for "bare iron" tests but runs into a problem when using virtual machines. The relationship between virtual guest and hypervisor can be thought of as being similar to that between a process and kernel in a bare iron system. As such, (m)any CPU utilization mechanisms used in the virtual guest are similar to "process-local" mechanisms in a bare iron situation. However, just as with bare iron and process-local mechanisms, much networking processing happens outside the context of the virtual guest. It takes place in the hypervisor, and is not visible to mechanisms running in the guest(s). For this reason, one should not really trust CPU utilization figures reported by netperf or netserver when running in a virtual guest. If one is looking to measure the added overhead of a virtualization mechanism, rather than rely on CPU utilization, one can rely instead on netperf _RR tests - path-lengths and overheads can be a significant fraction of the latency, so increases in overhead should appear as decreases in transaction rate. Whatever you do, DO NOT rely on the throughput of a _STREAM test. Achieving link-rate can be done via a multitude of options that mask overhead rather than eliminate it.  File: netperf.info, Node: Global Command-line Options, Next: Using Netperf to Measure Bulk Data Transfer, Prev: The Design of Netperf, Up: Top 4 Global Command-line Options ***************************** This section describes each of the global command-line options available in the netperf and netserver binaries. Essentially, it is an expanded version of the usage information displayed by netperf or netserver when invoked with the `-h' global command-line option. * Menu: * Command-line Options Syntax:: * Global Options::  File: netperf.info, Node: Command-line Options Syntax, Next: Global Options, Prev: Global Command-line Options, Up: Global Command-line Options 4.1 Command-line Options Syntax =============================== Revision 1.8 of netperf introduced enough new functionality to overrun the English alphabet for mnemonic command-line option names, and the author was not and is not quite ready to switch to the contemporary `--mumble' style of command-line options. (Call him a Luddite if you wish :). For this reason, the command-line options were split into two parts - the first are the global command-line options. They are options that affect nearly any and every test type of netperf. The second type are the test-specific command-line options. Both are entered on the same command line, but they must be separated from one another by a `--' for correct parsing. Global command-line options come first, followed by the `--' and then test-specific command-line options. If there are no test-specific options to be set, the `--' may be omitted. If there are no global command-line options to be set, test-specific options must still be preceded by a `--'. For example: netperf -- sets both global and test-specific options: netperf sets just global options and: netperf -- sets just test-specific options.  File: netperf.info, Node: Global Options, Prev: Command-line Options Syntax, Up: Global Command-line Options 4.2 Global Options ================== `-a ' This option allows you to alter the alignment of the buffers used in the sending and receiving calls on the local system.. Changing the alignment of the buffers can force the system to use different copy schemes, which can have a measurable effect on performance. If the page size for the system were 4096 bytes, and you want to pass page-aligned buffers beginning on page boundaries, you could use `-a 4096'. By default the units are bytes, but suffix of "G," "M," or "K" will specify the units to be 2^30 (GB), 2^20 (MB) or 2^10 (KB) respectively. A suffix of "g," "m" or "k" will specify units of 10^9, 10^6 or 10^3 bytes respectively. [Default: 8 bytes] `-A ' This option is identical to the `-a' option with the difference being it affects alignments for the remote system. `-b ' This option is only present when netperf has been configure with -enable-intervals=yes prior to compilation. It sets the size of the burst of send calls in a _STREAM test. When used in conjunction with the `-w' option it can cause the rate at which data is sent to be "paced." `-B ' This option will cause `' to be appended to the brief (see -P) output of netperf. `-c [rate]' This option will ask that CPU utilization and service demand be calculated for the local system. For those CPU utilization mechanisms requiring calibration, the options rate parameter may be specified to preclude running another calibration step, saving 40 seconds of time. For those CPU utilization mechanisms requiring no calibration, the optional rate parameter will be utterly and completely ignored. [Default: no CPU measurements] `-C [rate]' This option requests CPU utilization and service demand calculations for the remote system. It is otherwise identical to the `-c' option. `-d' Each instance of this option will increase the quantity of debugging output displayed during a test. If the debugging output level is set high enough, it may have a measurable effect on performance. Debugging information for the local system is printed to stdout. Debugging information for the remote system is sent by default to the file `/tmp/netperf.debug'. [Default: no debugging output] `-D [interval,units]' This option is only available when netperf is configured with -enable-demo=yes. When set, it will cause netperf to emit periodic reports of performance during the run. [INTERVAL,UNITS] follow the semantics of an optionspec. If specified, INTERVAL gives the minimum interval in real seconds, it does not have to be whole seconds. The UNITS value can be used for the first guess as to how many units of work (bytes or transactions) must be done to take at least INTERVAL seconds. If omitted, INTERVAL defaults to one second and UNITS to values specific to each test type. `-f G|M|K|g|m|k|x' This option can be used to change the reporting units for _STREAM tests. Arguments of "G," "M," or "K" will set the units to 2^30, 2^20 or 2^10 bytes/s respectively (EG power of two GB, MB or KB). Arguments of "g," ",m" or "k" will set the units to 10^9, 10^6 or 10^3 bits/s respectively. An argument of "x" requests the units be transactions per second and is only meaninful for a request-response test. [Default: "m" or 10^6 bits/s] `-F ' This option specified the file from which send which buffers will be pre-filled . While the buffers will contain data from the specified file, the file is not fully transfered to the remote system as the receiving end of the test will not write the contents of what it receives to a file. This can be used to pre-fill the send buffers with data having different compressibility and so is useful when measuring performance over mechanisms which perform compression. While previously required for a TCP_SENDFILE test, later versions of netperf removed that restriction, creating a temporary file as needed. While the author cannot recall exactly when that took place, it is known to be unnecessary in version 2.5.0 and later. `-h' This option causes netperf to display its "global" usage string and exit to the exclusion of all else. `-H ' This option will set the name of the remote system and or the address family used for the control connection. For example: -H linger,4 will set the name of the remote system to "linger" and tells netperf to use IPv4 addressing only. -H ,6 will leave the name of the remote system at its default, and request that only IPv6 addresses be used for the control connection. -H lag will set the name of the remote system to "lag" and leave the address family to AF_UNSPEC which means selection of IPv4 vs IPv6 is left to the system's address resolution. A value of "inet" can be used in place of "4" to request IPv4 only addressing. Similarly, a value of "inet6" can be used in place of "6" to request IPv6 only addressing. A value of "0" can be used to request either IPv4 or IPv6 addressing as name resolution dictates. By default, the options set with the global `-H' option are inherited by the test for its data connection, unless a test-specific `-H' option is specified. If a `-H' option follows either the `-4' or `-6' options, the family setting specified with the -H option will override the `-4' or `-6' options for the remote address family. If no address family is specified, settings from a previous `-4' or `-6' option will remain. In a nutshell, the last explicit global command-line option wins. [Default: "localhost" for the remote name/IP address and "0" (eg AF_UNSPEC) for the remote address family.] `-I ' This option enables the calculation of confidence intervals and sets the confidence and width parameters with the first half of the optionspec being either 99 or 95 for 99% or 95% confidence respectively. The second value of the optionspec specifies the width of the desired confidence interval. For example -I 99,5 asks netperf to be 99% confident that the measured mean values for throughput and CPU utilization are within +/- 2.5% of the "real" mean values. If the `-i' option is specified and the `-I' option is omitted, the confidence defaults to 99% and the width to 5% (giving +/- 2.5%) If classic netperf test calculates that the desired confidence intervals have not been met, it emits a noticeable warning that cannot be suppressed with the `-P' or `-v' options: netperf -H tardy.cup -i 3 -I 99,5 TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to tardy.cup.hp.com (15.244.44.58) port 0 AF_INET : +/-2.5% 99% conf. !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : 6.8% !!! Local CPU util : 0.0% !!! Remote CPU util : 0.0% Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 32768 16384 16384 10.01 40.23 In the example above we see that netperf did not meet the desired convidence intervals. Instead of being 99% confident it was within +/- 2.5% of the real mean value of throughput it is only confident it was within +/-3.4%. In this example, increasing the `-i' option (described below) and/or increasing the iteration length with the `-l' option might resolve the situation. In an explicit "omni" test, failure to meet the confidence intervals will not result in netperf emitting a warning. To verify the hitting, or not, of the confidence intervals one will need to include them as part of an an *note output selection: Omni Output Selection. in the test-specific `-o', `-O' or `k' output selection options. The warning about not hitting the confidence intervals will remain in a "migrated" classic netperf test. `-i ' This option enables the calculation of confidence intervals and sets the minimum and maximum number of iterations to run in attempting to achieve the desired confidence interval. The first value sets the maximum number of iterations to run, the second, the minimum. The maximum number of iterations is silently capped at 30 and the minimum is silently floored at 3. Netperf repeats the measurement the minimum number of iterations and continues until it reaches either the desired confidence interval, or the maximum number of iterations, whichever comes first. A classic or migrated netperf test will not display the actual number of iterations run. An *note omni test: The Omni Tests. will emit the number of iterations run if the `CONFIDENCE_ITERATION' output selector is included in the *note output selection: Omni Output Selection. If the `-I' option is specified and the `-i' option omitted the maximum number of iterations is set to 10 and the minimum to three. Output of a warning upon not hitting the desired confidence intervals follows the description provided for the `-I' option. The total test time will be somewhere between the minimum and maximum number of iterations multiplied by the test length supplied by the `-l' option. `-j' This option instructs netperf to keep additional timing statistics when explicitly running an *note omni test: The Omni Tests. These can be output when the test-specific `-o', `-O' or `-k' *note output selectors: Omni Output Selectors. include one or more of: * MIN_LATENCY * MAX_LATENCY * P50_LATENCY * P90_LATENCY * P99_LATENCY * MEAN_LATENCY * STDDEV_LATENCY These statistics will be based on an expanded (100 buckets per row rather than 10) histogram of times rather than a terribly long list of individual times. As such, there will be some slight error thanks to the bucketing. However, the reduction in storage and processing overheads is well worth it. When running a request/response test, one might get some idea of the error by comparing the *note `MEAN_LATENCY': Omni Output Selectors. calculated from the histogram with the `RT_LATENCY' calculated from the number of request/response transactions and the test run time. In the case of a request/response test the latencies will be transaction latencies. In the case of a receive-only test they will be time spent in the receive call. In the case of a send-only test they will be tim spent in the send call. The units will be microseconds. Added in netperf 2.5.0. `-l testlen' This option controls the length of any one iteration of the requested test. A positive value for TESTLEN will run each iteration of the test for at least TESTLEN seconds. A negative value for TESTLEN will run each iteration for the absolute value of TESTLEN transactions for a _RR test or bytes for a _STREAM test. Certain tests, notably those using UDP can only be timed, they cannot be limited by transaction or byte count. This limitation may be relaxed in an *note omni: The Omni Tests. test. In some situations, individual iterations of a test may run for longer for the number of seconds specified by the `-l' option. In particular, this may occur for those tests where the socket buffer size(s) are significantly longer than the bandwidthXdelay product of the link(s) over which the data connection passes, or those tests where there may be non-trivial numbers of retransmissions. If confidence intervals are enabled via either `-I' or `-i' the total length of the netperf test will be somewhere between the minimum and maximum iteration count multiplied by TESTLEN. `-L ' This option is identical to the `-H' option with the difference being it sets the _local_ hostname/IP and/or address family information. This option is generally unnecessary, but can be useful when you wish to make sure that the netperf control and data connections go via different paths. It can also come-in handy if one is trying to run netperf through those evil, end-to-end breaking things known as firewalls. [Default: 0.0.0.0 (eg INADDR_ANY) for IPv4 and ::0 for IPv6 for the local name. AF_UNSPEC for the local address family.] `-n numcpus' This option tells netperf how many CPUs it should ass-u-me are active on the system running netperf. In particular, this is used for the *note CPU utilization: CPU Utilization. and service demand calculations. On certain systems, netperf is able to determine the number of CPU's automagically. This option will override any number netperf might be able to determine on its own. Note that this option does _not_ set the number of CPUs on the system running netserver. When netperf/netserver cannot automagically determine the number of CPUs that can only be set for netserver via a netserver `-n' command-line option. As it is almost universally possible for netperf/netserver to determine the number of CPUs on the system automagically, 99 times out of 10 this option should not be necessary and may be removed in a future release of netperf. `-N' This option tells netperf to forego establishing a control connection. This makes it is possible to run some limited netperf tests without a corresponding netserver on the remote system. With this option set, the test to be run is to get all the addressing information it needs to establish its data connection from the command line or internal defaults. If not otherwise specified by test-specific command line options, the data connection for a "STREAM" or "SENDFILE" test will be to the "discard" port, an "RR" test will be to the "echo" port, and a "MEARTS" test will be to the chargen port. The response size of an "RR" test will be silently set to be the same as the request size. Otherwise the test would hang if the response size was larger than the request size, or would report an incorrect, inflated transaction rate if the response size was less than the request size. Since there is no control connection when this option is specified, it is not possible to set "remote" properties such as socket buffer size and the like via the netperf command line. Nor is it possible to retrieve such interesting remote information as CPU utilization. These items will be displayed as values which should make it immediately obvious that was the case. The only way to change remote characteristics such as socket buffer size or to obtain information such as CPU utilization is to employ platform-specific methods on the remote system. Frankly, if one has access to the remote system to employ those methods one aught to be able to run a netserver there. However, that ability may not be present in certain "support" situations, hence the addition of this option. Added in netperf 2.4.3. `-o ' The value(s) passed-in with this option will be used as an offset added to the alignment specified with the `-a' option. For example: -o 3 -a 4096 will cause the buffers passed to the local (netperf) send and receive calls to begin three bytes past an address aligned to 4096 bytes. [Default: 0 bytes] `-O ' This option behaves just as the `-o' option but on the remote (netserver) system and in conjunction with the `-A' option. [Default: 0 bytes] `-p ' The first value of the optionspec passed-in with this option tells netperf the port number at which it should expect the remote netserver to be listening for control connections. The second value of the optionspec will request netperf to bind to that local port number before establishing the control connection. For example -p 12345 tells netperf that the remote netserver is listening on port 12345 and leaves selection of the local port number for the control connection up to the local TCP/IP stack whereas -p ,32109 leaves the remote netserver port at the default value of 12865 and causes netperf to bind to the local port number 32109 before connecting to the remote netserver. In general, setting the local port number is only necessary when one is looking to run netperf through those evil, end-to-end breaking things known as firewalls. `-P 0|1' A value of "1" for the `-P' option will enable display of the test banner. A value of "0" will disable display of the test banner. One might want to disable display of the test banner when running the same basic test type (eg TCP_STREAM) multiple times in succession where the test banners would then simply be redundant and unnecessarily clutter the output. [Default: 1 - display test banners] `-s ' This option will cause netperf to sleep `' before actually transferring data over the data connection. This may be useful in situations where one wishes to start a great many netperf instances and do not want the earlier ones affecting the ability of the later ones to get established. Added somewhere between versions 2.4.3 and 2.5.0. `-S' This option will cause an attempt to be made to set SO_KEEPALIVE on the data socket of a test using the BSD sockets interface. The attempt will be made on the netperf side of all tests, and will be made on the netserver side of an *note omni: The Omni Tests. or *note migrated: Migrated Tests. test. No indication of failure is given unless debug output is enabled with the global `-d' option. Added in version 2.5.0. `-t testname' This option is used to tell netperf which test you wish to run. As of this writing, valid values for TESTNAME include: * *note TCP_STREAM::, *note TCP_MAERTS::, *note TCP_SENDFILE::, *note TCP_RR::, *note TCP_CRR::, *note TCP_CC:: * *note UDP_STREAM::, *note UDP_RR:: * *note XTI_TCP_STREAM::, *note XTI_TCP_RR::, *note XTI_TCP_CRR::, *note XTI_TCP_CC:: * *note XTI_UDP_STREAM::, *note XTI_UDP_RR:: * *note SCTP_STREAM::, *note SCTP_RR:: * *note DLCO_STREAM::, *note DLCO_RR::, *note DLCL_STREAM::, *note DLCL_RR:: * *note LOC_CPU: Other Netperf Tests, *note REM_CPU: Other Netperf Tests. * *note OMNI: The Omni Tests. Not all tests are always compiled into netperf. In particular, the "XTI," "SCTP," "UNIXDOMAIN," and "DL*" tests are only included in netperf when configured with `--enable-[xti|sctp|unixdomain|dlpi]=yes'. Netperf only runs one type of test no matter how many `-t' options may be present on the command-line. The last `-t' global command-line option will determine the test to be run. [Default: TCP_STREAM] `-T ' This option controls the CPU, and probably by extension memory, affinity of netperf and/or netserver. netperf -T 1 will bind both netperf and netserver to "CPU 1" on their respective systems. netperf -T 1, will bind just netperf to "CPU 1" and will leave netserver unbound. netperf -T ,2 will leave netperf unbound and will bind netserver to "CPU 2." netperf -T 1,2 will bind netperf to "CPU 1" and netserver to "CPU 2." This can be particularly useful when investigating performance issues involving where processes run relative to where NIC interrupts are processed or where NICs allocate their DMA buffers. `-v verbosity' This option controls how verbose netperf will be in its output, and is often used in conjunction with the `-P' option. If the verbosity is set to a value of "0" then only the test's SFM (Single Figure of Merit) is displayed. If local *note CPU utilization: CPU Utilization. is requested via the `-c' option then the SFM is the local service demand. Othersise, if remote CPU utilization is requested via the `-C' option then the SFM is the remote service demand. If neither local nor remote CPU utilization are requested the SFM will be the measured throughput or transaction rate as implied by the test specified with the `-t' option. If the verbosity level is set to "1" then the "normal" netperf result output for each test is displayed. If the verbosity level is set to "2" then "extra" information will be displayed. This may include, but is not limited to the number of send or recv calls made and the average number of bytes per send or recv call, or a histogram of the time spent in each send() call or for each transaction if netperf was configured with `--enable-histogram=yes'. [Default: 1 - normal verbosity] In an *note omni: The Omni Tests. test the verbosity setting is largely ignored, save for when asking for the time histogram to be displayed. In version 2.5.0 there is no *note output selector: Omni Output Selectors. for the histogram and so it remains displayed only when the verbosity level is set to 2. `-V' This option displays the netperf version and then exits. Added in netperf 2.4.4. `-w time' If netperf was configured with `--enable-intervals=yes' then this value will set the inter-burst time to time milliseconds, and the `-b' option will set the number of sends per burst. The actual inter-burst time may vary depending on the system's timer resolution. `-W ' This option controls the number of buffers in the send (first or only value) and or receive (second or only value) buffer rings. Unlike some benchmarks, netperf does not continuously send or receive from a single buffer. Instead it rotates through a ring of buffers. [Default: One more than the size of the send or receive socket buffer sizes (`-s' and/or `-S' options) divided by the send `-m' or receive `-M' buffer size respectively] `-4' Specifying this option will set both the local and remote address families to AF_INET - that is use only IPv4 addresses on the control connection. This can be overridden by a subsequent `-6', `-H' or `-L' option. Basically, the last option explicitly specifying an address family wins. Unless overridden by a test-specific option, this will be inherited for the data connection as well. `-6' Specifying this option will set both local and and remote address families to AF_INET6 - that is use only IPv6 addresses on the control connection. This can be overridden by a subsequent `-4', `-H' or `-L' option. Basically, the last address family explicitly specified wins. Unless overridden by a test-specific option, this will be inherited for the data connection as well.  File: netperf.info, Node: Using Netperf to Measure Bulk Data Transfer, Next: Using Netperf to Measure Request/Response, Prev: Global Command-line Options, Up: Top 5 Using Netperf to Measure Bulk Data Transfer ********************************************* The most commonly measured aspect of networked system performance is that of bulk or unidirectional transfer performance. Everyone wants to know how many bits or bytes per second they can push across the network. The classic netperf convention for a bulk data transfer test name is to tack a "_STREAM" suffix to a test name. * Menu: * Issues in Bulk Transfer:: * Options common to TCP UDP and SCTP tests::  File: netperf.info, Node: Issues in Bulk Transfer, Next: Options common to TCP UDP and SCTP tests, Prev: Using Netperf to Measure Bulk Data Transfer, Up: Using Netperf to Measure Bulk Data Transfer 5.1 Issues in Bulk Transfer =========================== There are any number of things which can affect the performance of a bulk transfer test. Certainly, absent compression, bulk-transfer tests can be limited by the speed of the slowest link in the path from the source to the destination. If testing over a gigabit link, you will not see more than a gigabit :) Such situations can be described as being "network-limited" or "NIC-limited". CPU utilization can also affect the results of a bulk-transfer test. If the networking stack requires a certain number of instructions or CPU cycles per KB of data transferred, and the CPU is limited in the number of instructions or cycles it can provide, then the transfer can be described as being "CPU-bound". A bulk-transfer test can be CPU bound even when netperf reports less than 100% CPU utilization. This can happen on an MP system where one or more of the CPUs saturate at 100% but other CPU's remain idle. Typically, a single flow of data, such as that from a single instance of a netperf _STREAM test cannot make use of much more than the power of one CPU. Exceptions to this generally occur when netperf and/or netserver run on CPU(s) other than the CPU(s) taking interrupts from the NIC(s). In that case, one might see as much as two CPUs' worth of processing being used to service the flow of data. Distance and the speed-of-light can affect performance for a bulk-transfer; often this can be mitigated by using larger windows. One common limit to the performance of a transport using window-based flow-control is: Throughput <= WindowSize/RoundTripTime As the sender can only have a window's-worth of data outstanding on the network at any one time, and the soonest the sender can receive a window update from the receiver is one RoundTripTime (RTT). TCP and SCTP are examples of such protocols. Packet losses and their effects can be particularly bad for performance. This is especially true if the packet losses result in retransmission timeouts for the protocol(s) involved. By the time a retransmission timeout has happened, the flow or connection has sat idle for a considerable length of time. On many platforms, some variant on the `netstat' command can be used to retrieve statistics about packet loss and retransmission. For example: netstat -p tcp will retrieve TCP statistics on the HP-UX Operating System. On other platforms, it may not be possible to retrieve statistics for a specific protocol and something like: netstat -s would be used instead. Many times, such network statistics are keep since the time the stack started, and we are only really interested in statistics from when netperf was running. In such situations something along the lines of: netstat -p tcp > before netperf -t TCP_mumble... netstat -p tcp > after is indicated. The beforeafter (ftp://ftp.cup.hp.com/dist/networking/tools/) utility can be used to subtract the statistics in `before' from the statistics in `after': beforeafter before after > delta and then one can look at the statistics in `delta'. Beforeafter is distributed in source form so one can compile it on the platform(s) of interest. If running a version 2.5.0 or later "omni" test under Linux one can include either or both of: * LOCAL_TRANSPORT_RETRANS * REMOTE_TRANSPORT_RETRANS in the values provided via a test-specific `-o', `-O', or `-k' output selction option and netperf will report the retransmissions experienced on the data connection, as reported via a `getsockopt(TCP_INFO)' call. If confidence intervals have been requested via the global `-I' or `-i' options, the reported value(s) will be for the last iteration. If the test is over a protocol other than TCP, or on a platform other than Linux, the results are undefined. While it was written with HP-UX's netstat in mind, the annotated netstat (ftp://ftp.cup.hp.com/dist/networking/briefs/annotated_netstat.txt) writeup may be helpful with other platforms as well.  File: netperf.info, Node: Options common to TCP UDP and SCTP tests, Prev: Issues in Bulk Transfer, Up: Using Netperf to Measure Bulk Data Transfer 5.2 Options common to TCP UDP and SCTP tests ============================================ Many "test-specific" options are actually common across the different tests. For those tests involving TCP, UDP and SCTP, whether using the BSD Sockets or the XTI interface those common options include: `-h' Display the test-suite-specific usage string and exit. For a TCP_ or UDP_ test this will be the usage string from the source file nettest_bsd.c. For an XTI_ test, this will be the usage string from the source file nettest_xti.c. For an SCTP test, this will be the usage string from the source file nettest_sctp.c. `-H ' Normally, the remote hostname|IP and address family information is inherited from the settings for the control connection (eg global command-line `-H', `-4' and/or `-6' options). The test-specific `-H' will override those settings for the data (aka test) connection only. Settings for the control connection are left unchanged. `-L ' The test-specific `-L' option is identical to the test-specific `-H' option except it affects the local hostname|IP and address family information. As with its global command-line counterpart, this is generally only useful when measuring though those evil, end-to-end breaking things called firewalls. `-m bytes' Set the size of the buffer passed-in to the "send" calls of a _STREAM test. Note that this may have only an indirect effect on the size of the packets sent over the network, and certain Layer 4 protocols do _not_ preserve or enforce message boundaries, so setting `-m' for the send size does not necessarily mean the receiver will receive that many bytes at any one time. By default the units are bytes, but suffix of "G," "M," or "K" will specify the units to be 2^30 (GB), 2^20 (MB) or 2^10 (KB) respectively. A suffix of "g," "m" or "k" will specify units of 10^9, 10^6 or 10^3 bytes respectively. For example: `-m 32K' will set the size to 32KB or 32768 bytes. [Default: the local send socket buffer size for the connection - either the system's default or the value set via the `-s' option.] `-M bytes' Set the size of the buffer passed-in to the "recv" calls of a _STREAM test. This will be an upper bound on the number of bytes received per receive call. By default the units are bytes, but suffix of "G," "M," or "K" will specify the units to be 2^30 (GB), 2^20 (MB) or 2^10 (KB) respectively. A suffix of "g," "m" or "k" will specify units of 10^9, 10^6 or 10^3 bytes respectively. For example: `-M 32K' will set the size to 32KB or 32768 bytes. [Default: the remote receive socket buffer size for the data connection - either the system's default or the value set via the `-S' option.] `-P ' Set the local and/or remote port numbers for the data connection. `-s ' This option sets the local (netperf) send and receive socket buffer sizes for the data connection to the value(s) specified. Often, this will affect the advertised and/or effective TCP or other window, but on some platforms it may not. By default the units are bytes, but suffix of "G," "M," or "K" will specify the units to be 2^30 (GB), 2^20 (MB) or 2^10 (KB) respectively. A suffix of "g," "m" or "k" will specify units of 10^9, 10^6 or 10^3 bytes respectively. For example: `-s 128K' Will request the local send and receive socket buffer sizes to be 128KB or 131072 bytes. While the historic expectation is that setting the socket buffer size has a direct effect on say the TCP window, today that may not hold true for all stacks. Further, while the historic expectation is that the value specified in a `setsockopt()' call will be the value returned via a `getsockopt()' call, at least one stack is known to deliberately ignore history. When running under Windows a value of 0 may be used which will be an indication to the stack the user wants to enable a form of copy avoidance. [Default: -1 - use the system's default socket buffer sizes] `-S ' This option sets the remote (netserver) send and/or receive socket buffer sizes for the data connection to the value(s) specified. Often, this will affect the advertised and/or effective TCP or other window, but on some platforms it may not. By default the units are bytes, but suffix of "G," "M," or "K" will specify the units to be 2^30 (GB), 2^20 (MB) or 2^10 (KB) respectively. A suffix of "g," "m" or "k" will specify units of 10^9, 10^6 or 10^3 bytes respectively. For example: `-s 128K' Will request the remote send and receive socket buffer sizes to be 128KB or 131072 bytes. While the historic expectation is that setting the socket buffer size has a direct effect on say the TCP window, today that may not hold true for all stacks. Further, while the historic expectation is that the value specified in a `setsockopt()' call will be the value returned via a `getsockopt()' call, at least one stack is known to deliberately ignore history. When running under Windows a value of 0 may be used which will be an indication to the stack the user wants to enable a form of copy avoidance. [Default: -1 - use the system's default socket buffer sizes] `-4' Set the local and remote address family for the data connection to AF_INET - ie use IPv4 addressing only. Just as with their global command-line counterparts the last of the `-4', `-6', `-H' or `-L' option wins for their respective address families. `-6' This option is identical to its `-4' cousin, but requests IPv6 addresses for the local and remote ends of the data connection. * Menu: * TCP_STREAM:: * TCP_MAERTS:: * TCP_SENDFILE:: * UDP_STREAM:: * XTI_TCP_STREAM:: * XTI_UDP_STREAM:: * SCTP_STREAM:: * DLCO_STREAM:: * DLCL_STREAM:: * STREAM_STREAM:: * DG_STREAM::  File: netperf.info, Node: TCP_STREAM, Next: TCP_MAERTS, Prev: Options common to TCP UDP and SCTP tests, Up: Options common to TCP UDP and SCTP tests 5.2.1 TCP_STREAM ---------------- The TCP_STREAM test is the default test in netperf. It is quite simple, transferring some quantity of data from the system running netperf to the system running netserver. While time spent establishing the connection is not included in the throughput calculation, time spent flushing the last of the data to the remote at the end of the test is. This is how netperf knows that all the data it sent was received by the remote. In addition to the *note options common to STREAM tests: Options common to TCP UDP and SCTP tests, the following test-specific options can be included to possibly alter the behavior of the test: `-C' This option will set TCP_CORK mode on the data connection on those systems where TCP_CORK is defined (typically Linux). A full description of TCP_CORK is beyond the scope of this manual, but in a nutshell it forces sub-MSS sends to be buffered so every segment sent is Maximum Segment Size (MSS) unless the application performs an explicit flush operation or the connection is closed. At present netperf does not perform any explicit flush operations. Setting TCP_CORK may improve the bitrate of tests where the "send size" (`-m' option) is smaller than the MSS. It should also improve (make smaller) the service demand. The Linux tcp(7) manpage states that TCP_CORK cannot be used in conjunction with TCP_NODELAY (set via the `-d' option), however netperf does not validate command-line options to enforce that. `-D' This option will set TCP_NODELAY on the data connection on those systems where TCP_NODELAY is defined. This disables something known as the Nagle Algorithm, which is intended to make the segments TCP sends as large as reasonably possible. Setting TCP_NODELAY for a TCP_STREAM test should either have no effect when the send size (`-m' option) is larger than the MSS or will decrease reported bitrate and increase service demand when the send size is smaller than the MSS. This stems from TCP_NODELAY causing each sub-MSS send to be its own TCP segment rather than being aggregated with other small sends. This means more trips up and down the protocol stack per KB of data transferred, which means greater CPU utilization. If setting TCP_NODELAY with `-D' affects throughput and/or service demand for tests where the send size (`-m') is larger than the MSS it suggests the TCP/IP stack's implementation of the Nagle Algorithm _may_ be broken, perhaps interpreting the Nagle Algorithm on a segment by segment basis rather than the proper user send by user send basis. However, a better test of this can be achieved with the *note TCP_RR:: test. Here is an example of a basic TCP_STREAM test, in this case from a Debian Linux (2.6 kernel) system to an HP-UX 11iv2 (HP-UX 11.23) system: $ netperf -H lag TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to lag.hpl.hp.com (15.4.89.214) port 0 AF_INET Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 32768 16384 16384 10.00 80.42 We see that the default receive socket buffer size for the receiver (lag - HP-UX 11.23) is 32768 bytes, and the default socket send buffer size for the sender (Debian 2.6 kernel) is 16384 bytes, however Linux does "auto tuning" of socket buffer and TCP window sizes, which means the send socket buffer size may be different at the end of the test than it was at the beginning. This is addressed in the *note omni tests: The Omni Tests. added in version 2.5.0 and *note output selection: Omni Output Selection. Througput is expressed as 10^6 (aka Mega) bits per second, and the test ran for 10 seconds. IPv4 addresses (AF_INET) were used.  File: netperf.info, Node: TCP_MAERTS, Next: TCP_SENDFILE, Prev: TCP_STREAM, Up: Options common to TCP UDP and SCTP tests 5.2.2 TCP_MAERTS ---------------- A TCP_MAERTS (MAERTS is STREAM backwards) test is "just like" a *note TCP_STREAM:: test except the data flows from the netserver to the netperf. The global command-line `-F' option is ignored for this test type. The test-specific command-line `-C' option is ignored for this test type. Here is an example of a TCP_MAERTS test between the same two systems as in the example for the *note TCP_STREAM:: test. This time we request larger socket buffers with `-s' and `-S' options: $ netperf -H lag -t TCP_MAERTS -- -s 128K -S 128K TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to lag.hpl.hp.com (15.4.89.214) port 0 AF_INET Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 221184 131072 131072 10.03 81.14 Where we see that Linux, unlike HP-UX, may not return the same value in a `getsockopt()' as was requested in the prior `setsockopt()'. This test is included more for benchmarking convenience than anything else.  File: netperf.info, Node: TCP_SENDFILE, Next: UDP_STREAM, Prev: TCP_MAERTS, Up: Options common to TCP UDP and SCTP tests 5.2.3 TCP_SENDFILE ------------------ The TCP_SENDFILE test is "just like" a *note TCP_STREAM:: test except netperf the platform's `sendfile()' call instead of calling `send()'. Often this results in a "zero-copy" operation where data is sent directly from the filesystem buffer cache. This _should_ result in lower CPU utilization and possibly higher throughput. If it does not, then you may want to contact your vendor(s) because they have a problem on their hands. Zero-copy mechanisms may also alter the characteristics (size and number of buffers per) of packets passed to the NIC. In many stacks, when a copy is performed, the stack can "reserve" space at the beginning of the destination buffer for things like TCP, IP and Link headers. This then has the packet contained in a single buffer which can be easier to DMA to the NIC. When no copy is performed, there is no opportunity to reserve space for headers and so a packet will be contained in two or more buffers. As of some time before version 2.5.0, the *note global `-F' option: Global Options. is no longer required for this test. If it is not specified, netperf will create a temporary file, which it will delete at the end of the test. If the `-F' option is specified it must reference a file of at least the size of the send ring (*Note the global `-W' option: Global Options.) multiplied by the send size (*Note the test-specific `-m' option: Options common to TCP UDP and SCTP tests.). All other TCP-specific options remain available and optional. In this first example: $ netperf -H lag -F ../src/netperf -t TCP_SENDFILE -- -s 128K -S 128K TCP SENDFILE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to lag.hpl.hp.com (15.4.89.214) port 0 AF_INET alloc_sendfile_buf_ring: specified file too small. file must be larger than send_width * send_size we see what happens when the file is too small. Here: $ netperf -H lag -F /boot/vmlinuz-2.6.8-1-686 -t TCP_SENDFILE -- -s 128K -S 128K TCP SENDFILE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to lag.hpl.hp.com (15.4.89.214) port 0 AF_INET Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 131072 221184 221184 10.02 81.83 we resolve that issue by selecting a larger file.  File: netperf.info, Node: UDP_STREAM, Next: XTI_TCP_STREAM, Prev: TCP_SENDFILE, Up: Options common to TCP UDP and SCTP tests 5.2.4 UDP_STREAM ---------------- A UDP_STREAM test is similar to a *note TCP_STREAM:: test except UDP is used as the transport rather than TCP. A UDP_STREAM test has no end-to-end flow control - UDP provides none and neither does netperf. However, if you wish, you can configure netperf with `--enable-intervals=yes' to enable the global command-line `-b' and `-w' options to pace bursts of traffic onto the network. This has a number of implications. The biggest of these implications is the data which is sent might not be received by the remote. For this reason, the output of a UDP_STREAM test shows both the sending and receiving throughput. On some platforms, it may be possible for the sending throughput to be reported as a value greater than the maximum rate of the link. This is common when the CPU(s) are faster than the network and there is no "intra-stack" flow-control. Here is an example of a UDP_STREAM test between two systems connected by a 10 Gigabit Ethernet link: $ netperf -t UDP_STREAM -H 192.168.2.125 -- -m 32768 UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.2.125 (192.168.2.125) port 0 AF_INET Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 124928 32768 10.00 105672 0 2770.20 135168 10.00 104844 2748.50 The first line of numbers are statistics from the sending (netperf) side. The second line of numbers are from the receiving (netserver) side. In this case, 105672 - 104844 or 828 messages did not make it all the way to the remote netserver process. If the value of the `-m' option is larger than the local send socket buffer size (`-s' option) netperf will likely abort with an error message about how the send call failed: netperf -t UDP_STREAM -H 192.168.2.125 UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.2.125 (192.168.2.125) port 0 AF_INET udp_send: data send error: Message too long If the value of the `-m' option is larger than the remote socket receive buffer, the reported receive throughput will likely be zero as the remote UDP will discard the messages as being too large to fit into the socket buffer. $ netperf -t UDP_STREAM -H 192.168.2.125 -- -m 65000 -S 32768 UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.2.125 (192.168.2.125) port 0 AF_INET Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 124928 65000 10.00 53595 0 2786.99 65536 10.00 0 0.00 The example above was between a pair of systems running a "Linux" kernel. Notice that the remote Linux system returned a value larger than that passed-in to the `-S' option. In fact, this value was larger than the message size set with the `-m' option. That the remote socket buffer size is reported as 65536 bytes would suggest to any sane person that a message of 65000 bytes would fit, but the socket isn't _really_ 65536 bytes, even though Linux is telling us so. Go figure.  File: netperf.info, Node: XTI_TCP_STREAM, Next: XTI_UDP_STREAM, Prev: UDP_STREAM, Up: Options common to TCP UDP and SCTP tests 5.2.5 XTI_TCP_STREAM -------------------- An XTI_TCP_STREAM test is simply a *note TCP_STREAM:: test using the XTI rather than BSD Sockets interface. The test-specific `-X ' option can be used to specify the name of the local and/or remote XTI device files, which is required by the `t_open()' call made by netperf XTI tests. The XTI_TCP_STREAM test is only present if netperf was configured with `--enable-xti=yes'. The remote netserver must have also been configured with `--enable-xti=yes'.  File: netperf.info, Node: XTI_UDP_STREAM, Next: SCTP_STREAM, Prev: XTI_TCP_STREAM, Up: Options common to TCP UDP and SCTP tests 5.2.6 XTI_UDP_STREAM -------------------- An XTI_UDP_STREAM test is simply a *note UDP_STREAM:: test using the XTI rather than BSD Sockets Interface. The test-specific `-X ' option can be used to specify the name of the local and/or remote XTI device files, which is required by the `t_open()' call made by netperf XTI tests. The XTI_UDP_STREAM test is only present if netperf was configured with `--enable-xti=yes'. The remote netserver must have also been configured with `--enable-xti=yes'.  File: netperf.info, Node: SCTP_STREAM, Next: DLCO_STREAM, Prev: XTI_UDP_STREAM, Up: Options common to TCP UDP and SCTP tests 5.2.7 SCTP_STREAM ----------------- An SCTP_STREAM test is essentially a *note TCP_STREAM:: test using the SCTP rather than TCP. The `-D' option will set SCTP_NODELAY, which is much like the TCP_NODELAY option for TCP. The `-C' option is not applicable to an SCTP test as there is no corresponding SCTP_CORK option. The author is still figuring-out what the test-specific `-N' option does :) The SCTP_STREAM test is only present if netperf was configured with `--enable-sctp=yes'. The remote netserver must have also been configured with `--enable-sctp=yes'.  File: netperf.info, Node: DLCO_STREAM, Next: DLCL_STREAM, Prev: SCTP_STREAM, Up: Options common to TCP UDP and SCTP tests 5.2.8 DLCO_STREAM ----------------- A DLPI Connection Oriented Stream (DLCO_STREAM) test is very similar in concept to a *note TCP_STREAM:: test. Both use reliable, connection-oriented protocols. The DLPI test differs from the TCP test in that its protocol operates only at the link-level and does not include TCP-style segmentation and reassembly. This last difference means that the value passed-in with the `-m' option must be less than the interface MTU. Otherwise, the `-m' and `-M' options are just like their TCP/UDP/SCTP counterparts. Other DLPI-specific options include: `-D ' This option is used to provide the fully-qualified names for the local and/or remote DPLI device files. The syntax is otherwise identical to that of a "sizespec". `-p ' This option is used to specify the local and/or remote DLPI PPA(s). The PPA is used to identify the interface over which traffic is to be sent/received. The syntax of a "ppaspec" is otherwise the same as a "sizespec". `-s sap' This option specifies the 802.2 SAP for the test. A SAP is somewhat like either the port field of a TCP or UDP header or the protocol field of an IP header. The specified SAP should not conflict with any other active SAPs on the specified PPA's (`-p' option). `-w ' This option specifies the local send and receive window sizes in units of frames on those platforms which support setting such things. `-W ' This option specifies the remote send and receive window sizes in units of frames on those platforms which support setting such things. The DLCO_STREAM test is only present if netperf was configured with `--enable-dlpi=yes'. The remote netserver must have also been configured with `--enable-dlpi=yes'.  File: netperf.info, Node: DLCL_STREAM, Next: STREAM_STREAM, Prev: DLCO_STREAM, Up: Options common to TCP UDP and SCTP tests 5.2.9 DLCL_STREAM ----------------- A DLPI ConnectionLess Stream (DLCL_STREAM) test is analogous to a *note UDP_STREAM:: test in that both make use of unreliable/best-effort, connection-less transports. The DLCL_STREAM test differs from the *note UDP_STREAM:: test in that the message size (`-m' option) must always be less than the link MTU as there is no IP-like fragmentation and reassembly available and netperf does not presume to provide one. The test-specific command-line options for a DLCL_STREAM test are the same as those for a *note DLCO_STREAM:: test. The DLCL_STREAM test is only present if netperf was configured with `--enable-dlpi=yes'. The remote netserver must have also been configured with `--enable-dlpi=yes'.  File: netperf.info, Node: STREAM_STREAM, Next: DG_STREAM, Prev: DLCL_STREAM, Up: Options common to TCP UDP and SCTP tests 5.2.10 STREAM_STREAM -------------------- A Unix Domain Stream Socket Stream test (STREAM_STREAM) is similar in concept to a *note TCP_STREAM:: test, but using Unix Domain sockets. It is, naturally, limited to intra-machine traffic. A STREAM_STREAM test shares the `-m', `-M', `-s' and `-S' options of the other _STREAM tests. In a STREAM_STREAM test the `-p' option sets the directory in which the pipes will be created rather than setting a port number. The default is to create the pipes in the system default for the `tempnam()' call. The STREAM_STREAM test is only present if netperf was configured with `--enable-unixdomain=yes'. The remote netserver must have also been configured with `--enable-unixdomain=yes'.  File: netperf.info, Node: DG_STREAM, Prev: STREAM_STREAM, Up: Options common to TCP UDP and SCTP tests 5.2.11 DG_STREAM ---------------- A Unix Domain Datagram Socket Stream test (SG_STREAM) is very much like a *note TCP_STREAM:: test except that message boundaries are preserved. In this way, it may also be considered similar to certain flavors of SCTP test which can also preserve message boundaries. All the options of a *note STREAM_STREAM:: test are applicable to a DG_STREAM test. The DG_STREAM test is only present if netperf was configured with `--enable-unixdomain=yes'. The remote netserver must have also been configured with `--enable-unixdomain=yes'.  File: netperf.info, Node: Using Netperf to Measure Request/Response, Next: Using Netperf to Measure Aggregate Performance, Prev: Using Netperf to Measure Bulk Data Transfer, Up: Top 6 Using Netperf to Measure Request/Response ******************************************* Request/response performance is often overlooked, yet it is just as important as bulk-transfer performance. While things like larger socket buffers and TCP windows, and stateless offloads like TSO and LRO can cover a multitude of latency and even path-length sins, those sins cannot easily hide from a request/response test. The convention for a request/response test is to have a _RR suffix. There are however a few "request/response" tests that have other suffixes. A request/response test, particularly synchronous, one transaction at at time test such as those found by default in netperf, is particularly sensitive to the path-length of the networking stack. An _RR test can also uncover those platforms where the NIC's are strapped by default with overbearing interrupt avoidance settings in an attempt to increase the bulk-transfer performance (or rather, decrease the CPU utilization of a bulk-transfer test). This sensitivity is most acute for small request and response sizes, such as the single-byte default for a netperf _RR test. While a bulk-transfer test reports its results in units of bits or bytes transfered per second, by default a mumble_RR test reports transactions per second where a transaction is defined as the completed exchange of a request and a response. One can invert the transaction rate to arrive at the average round-trip latency. If one is confident about the symmetry of the connection, the average one-way latency can be taken as one-half the average round-trip latency. As of version 2.5.0 (actually slightly before) netperf still does not do the latter, but will do the former if one sets the verbosity to 2 for a classic netperf test, or includes the apropriate *note output selector: Omni Output Selectors. in an *note omni test: The Omni Tests. It will also allow the user to switch the throughput units from transactions per secont to bits or bytes per second with the global `-f' option. * Menu: * Issues in Request/Response:: * Options Common to TCP UDP and SCTP _RR tests::  File: netperf.info, Node: Issues in Request/Response, Next: Options Common to TCP UDP and SCTP _RR tests, Prev: Using Netperf to Measure Request/Response, Up: Using Netperf to Measure Request/Response 6.1 Issues in Request/Response ============================== Most if not all the *note Issues in Bulk Transfer:: apply to request/response. The issue of round-trip latency is even more important as netperf generally only has one transaction outstanding at a time. A single instance of a one transaction outstanding _RR test should _never_ completely saturate the CPU of a system. If testing between otherwise evenly matched systems, the symmetric nature of a _RR test with equal request and response sizes should result in equal CPU loading on both systems. However, this may not hold true on MP systems, particularly if one CPU binds the netperf and netserver differently via the global `-T' option. For smaller request and response sizes packet loss is a bigger issue as there is no opportunity for a "fast retransmit" or retransmission prior to a retransmission timer expiring. Virtualization may considerably increase the effective path length of a networking stack. While this may not preclude achieving link-rate on a comparatively slow link (eg 1 Gigabit Ethernet) on a _STREAM test, it can show-up as measurably fewer transactions per second on an _RR test. However, this may still be masked by interrupt coalescing in the NIC/driver. Certain NICs have ways to minimize the number of interrupts sent to the host. If these are strapped badly they can significantly reduce the performance of something like a single-byte request/response test. Such setups are distinguised by seriously low reported CPU utilization and what seems like a low (even if in the thousands) transaction per second rate. Also, if you run such an OS/driver combination on faster or slower hardware and do not see a corresponding change in the transaction rate, chances are good that the drvier is strapping the NIC with aggressive interrupt avoidance settings. Good for bulk throughput, but bad for latency. Some drivers may try to automagically adjust the interrupt avoidance settings. If they are not terribly good at it, you will see considerable run-to-run variation in reported transaction rates. Particularly if you "mix-up" _STREAM and _RR tests.  File: netperf.info, Node: Options Common to TCP UDP and SCTP _RR tests, Prev: Issues in Request/Response, Up: Using Netperf to Measure Request/Response 6.2 Options Common to TCP UDP and SCTP _RR tests ================================================ Many "test-specific" options are actually common across the different tests. For those tests involving TCP, UDP and SCTP, whether using the BSD Sockets or the XTI interface those common options include: `-h' Display the test-suite-specific usage string and exit. For a TCP_ or UDP_ test this will be the usage string from the source file `nettest_bsd.c'. For an XTI_ test, this will be the usage string from the source file `src/nettest_xti.c'. For an SCTP test, this will be the usage string from the source file `src/nettest_sctp.c'. `-H ' Normally, the remote hostname|IP and address family information is inherited from the settings for the control connection (eg global command-line `-H', `-4' and/or `-6' options. The test-specific `-H' will override those settings for the data (aka test) connection only. Settings for the control connection are left unchanged. This might be used to cause the control and data connections to take different paths through the network. `-L ' The test-specific `-L' option is identical to the test-specific `-H' option except it affects the local hostname|IP and address family information. As with its global command-line counterpart, this is generally only useful when measuring though those evil, end-to-end breaking things called firewalls. `-P ' Set the local and/or remote port numbers for the data connection. `-r ' This option sets the request (first value) and/or response (second value) sizes for an _RR test. By default the units are bytes, but a suffix of "G," "M," or "K" will specify the units to be 2^30 (GB), 2^20 (MB) or 2^10 (KB) respectively. A suffix of "g," "m" or "k" will specify units of 10^9, 10^6 or 10^3 bytes respectively. For example: `-r 128,16K' Will set the request size to 128 bytes and the response size to 16 KB or 16384 bytes. [Default: 1 - a single-byte request and response ] `-s ' This option sets the local (netperf) send and receive socket buffer sizes for the data connection to the value(s) specified. Often, this will affect the advertised and/or effective TCP or other window, but on some platforms it may not. By default the units are bytes, but a suffix of "G," "M," or "K" will specify the units to be 2^30 (GB), 2^20 (MB) or 2^10 (KB) respectively. A suffix of "g," "m" or "k" will specify units of 10^9, 10^6 or 10^3 bytes respectively. For example: `-s 128K' Will request the local send (netperf) and receive socket buffer sizes to be 128KB or 131072 bytes. While the historic expectation is that setting the socket buffer size has a direct effect on say the TCP window, today that may not hold true for all stacks. When running under Windows a value of 0 may be used which will be an indication to the stack the user wants to enable a form of copy avoidance. [Default: -1 - use the system's default socket buffer sizes] `-S ' This option sets the remote (netserver) send and/or receive socket buffer sizes for the data connection to the value(s) specified. Often, this will affect the advertised and/or effective TCP or other window, but on some platforms it may not. By default the units are bytes, but a suffix of "G," "M," or "K" will specify the units to be 2^30 (GB), 2^20 (MB) or 2^10 (KB) respectively. A suffix of "g," "m" or "k" will specify units of 10^9, 10^6 or 10^3 bytes respectively. For example: `-s 128K' Will request the remote (netserver) send and receive socket buffer sizes to be 128KB or 131072 bytes. While the historic expectation is that setting the socket buffer size has a direct effect on say the TCP window, today that may not hold true for all stacks. When running under Windows a value of 0 may be used which will be an indication to the stack the user wants to enable a form of copy avoidance. [Default: -1 - use the system's default socket buffer sizes] `-4' Set the local and remote address family for the data connection to AF_INET - ie use IPv4 addressing only. Just as with their global command-line counterparts the last of the `-4', `-6', `-H' or `-L' option wins for their respective address families. `-6' This option is identical to its `-4' cousin, but requests IPv6 addresses for the local and remote ends of the data connection. * Menu: * TCP_RR:: * TCP_CC:: * TCP_CRR:: * UDP_RR:: * XTI_TCP_RR:: * XTI_TCP_CC:: * XTI_TCP_CRR:: * XTI_UDP_RR:: * DLCL_RR:: * DLCO_RR:: * SCTP_RR::  File: netperf.info, Node: TCP_RR, Next: TCP_CC, Prev: Options Common to TCP UDP and SCTP _RR tests, Up: Options Common to TCP UDP and SCTP _RR tests 6.2.1 TCP_RR ------------ A TCP_RR (TCP Request/Response) test is requested by passing a value of "TCP_RR" to the global `-t' command-line option. A TCP_RR test can be thought-of as a user-space to user-space `ping' with no think time - it is by default a synchronous, one transaction at a time, request/response test. The transaction rate is the number of complete transactions exchanged divided by the length of time it took to perform those transactions. If the two Systems Under Test are otherwise identical, a TCP_RR test with the same request and response size should be symmetric - it should not matter which way the test is run, and the CPU utilization measured should be virtually the same on each system. If not, it suggests that the CPU utilization mechanism being used may have some, well, issues measuring CPU utilization completely and accurately. Time to establish the TCP connection is not counted in the result. If you want connection setup overheads included, you should consider the *note TPC_CC: TCP_CC. or *note TCP_CRR: TCP_CRR. tests. If specifying the `-D' option to set TCP_NODELAY and disable the Nagle Algorithm increases the transaction rate reported by a TCP_RR test, it implies the stack(s) over which the TCP_RR test is running have a broken implementation of the Nagle Algorithm. Likely as not they are interpreting Nagle on a segment by segment basis rather than a user send by user send basis. You should contact your stack vendor(s) to report the problem to them. Here is an example of two systems running a basic TCP_RR test over a 10 Gigabit Ethernet link: netperf -t TCP_RR -H 192.168.2.125 TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.2.125 (192.168.2.125) port 0 AF_INET Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 16384 87380 1 1 10.00 29150.15 16384 87380 In this example the request and response sizes were one byte, the socket buffers were left at their defaults, and the test ran for all of 10 seconds. The transaction per second rate was rather good for the time :)  File: netperf.info, Node: TCP_CC, Next: TCP_CRR, Prev: TCP_RR, Up: Options Common to TCP UDP and SCTP _RR tests 6.2.2 TCP_CC ------------ A TCP_CC (TCP Connect/Close) test is requested by passing a value of "TCP_CC" to the global `-t' option. A TCP_CC test simply measures how fast the pair of systems can open and close connections between one another in a synchronous (one at a time) manner. While this is considered an _RR test, no request or response is exchanged over the connection. The issue of TIME_WAIT reuse is an important one for a TCP_CC test. Basically, TIME_WAIT reuse is when a pair of systems churn through connections fast enough that they wrap the 16-bit port number space in less time than the length of the TIME_WAIT state. While it is indeed theoretically possible to "reuse" a connection in TIME_WAIT, the conditions under which such reuse is possible are rather rare. An attempt to reuse a connection in TIME_WAIT can result in a non-trivial delay in connection establishment. Basically, any time the connection churn rate approaches: Sizeof(clientportspace) / Lengthof(TIME_WAIT) there is the risk of TIME_WAIT reuse. To minimize the chances of this happening, netperf will by default select its own client port numbers from the range of 5000 to 65535. On systems with a 60 second TIME_WAIT state, this should allow roughly 1000 transactions per second. The size of the client port space used by netperf can be controlled via the test-specific `-p' option, which takes a "sizespec" as a value setting the minimum (first value) and maximum (second value) port numbers used by netperf at the client end. Since no requests or responses are exchanged during a TCP_CC test, only the `-H', `-L', `-4' and `-6' of the "common" test-specific options are likely to have an effect, if any, on the results. The `-s' and `-S' options _may_ have some effect if they alter the number and/or type of options carried in the TCP SYNchronize segments, such as Window Scaling or Timestamps. The `-P' and `-r' options are utterly ignored. Since connection establishment and tear-down for TCP is not symmetric, a TCP_CC test is not symmetric in its loading of the two systems under test.  File: netperf.info, Node: TCP_CRR, Next: UDP_RR, Prev: TCP_CC, Up: Options Common to TCP UDP and SCTP _RR tests 6.2.3 TCP_CRR ------------- The TCP Connect/Request/Response (TCP_CRR) test is requested by passing a value of "TCP_CRR" to the global `-t' command-line option. A TCP_CRR test is like a merger of a *note TCP_RR:: and *note TCP_CC:: test which measures the performance of establishing a connection, exchanging a single request/response transaction, and tearing-down that connection. This is very much like what happens in an HTTP 1.0 or HTTP 1.1 connection when HTTP Keepalives are not used. In fact, the TCP_CRR test was added to netperf to simulate just that. Since a request and response are exchanged the `-r', `-s' and `-S' options can have an effect on the performance. The issue of TIME_WAIT reuse exists for the TCP_CRR test just as it does for the TCP_CC test. Similarly, since connection establishment and tear-down is not symmetric, a TCP_CRR test is not symmetric even when the request and response sizes are the same.  File: netperf.info, Node: UDP_RR, Next: XTI_TCP_RR, Prev: TCP_CRR, Up: Options Common to TCP UDP and SCTP _RR tests 6.2.4 UDP_RR ------------ A UDP Request/Response (UDP_RR) test is requested by passing a value of "UDP_RR" to a global `-t' option. It is very much the same as a TCP_RR test except UDP is used rather than TCP. UDP does not provide for retransmission of lost UDP datagrams, and netperf does not add anything for that either. This means that if _any_ request or response is lost, the exchange of requests and responses will stop from that point until the test timer expires. Netperf will not really "know" this has happened - the only symptom will be a low transaction per second rate. If `--enable-burst' was included in the `configure' command and a test-specific `-b' option used, the UDP_RR test will "survive" the loss of requests and responses until the sum is one more than the value passed via the `-b' option. It will though almost certainly run more slowly. The netperf side of a UDP_RR test will call `connect()' on its data socket and thenceforth use the `send()' and `recv()' socket calls. The netserver side of a UDP_RR test will not call `connect()' and will use `recvfrom()' and `sendto()' calls. This means that even if the request and response sizes are the same, a UDP_RR test is _not_ symmetric in its loading of the two systems under test. Here is an example of a UDP_RR test between two otherwise identical two-CPU systems joined via a 1 Gigabit Ethernet network: $ netperf -T 1 -H 192.168.1.213 -t UDP_RR -c -C UDP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.1.213 (192.168.1.213) port 0 AF_INET Local /Remote Socket Size Request Resp. Elapsed Trans. CPU CPU S.dem S.dem Send Recv Size Size Time Rate local remote local remote bytes bytes bytes bytes secs. per sec % I % I us/Tr us/Tr 65535 65535 1 1 10.01 15262.48 13.90 16.11 18.221 21.116 65535 65535 This example includes the `-c' and `-C' options to enable CPU utilization reporting and shows the asymmetry in CPU loading. The `-T' option was used to make sure netperf and netserver ran on a given CPU and did not move around during the test.  File: netperf.info, Node: XTI_TCP_RR, Next: XTI_TCP_CC, Prev: UDP_RR, Up: Options Common to TCP UDP and SCTP _RR tests 6.2.5 XTI_TCP_RR ---------------- An XTI_TCP_RR test is essentially the same as a *note TCP_RR:: test only using the XTI rather than BSD Sockets interface. It is requested by passing a value of "XTI_TCP_RR" to the `-t' global command-line option. The test-specific options for an XTI_TCP_RR test are the same as those for a TCP_RR test with the addition of the `-X ' option to specify the names of the local and/or remote XTI device file(s).  File: netperf.info, Node: XTI_TCP_CC, Next: XTI_TCP_CRR, Prev: XTI_TCP_RR, Up: Options Common to TCP UDP and SCTP _RR tests 6.2.6 XTI_TCP_CC ---------------- An XTI_TCP_CC test is essentially the same as a *note TCP_CC: TCP_CC. test, only using the XTI rather than BSD Sockets interface. The test-specific options for an XTI_TCP_CC test are the same as those for a TCP_CC test with the addition of the `-X ' option to specify the names of the local and/or remote XTI device file(s).  File: netperf.info, Node: XTI_TCP_CRR, Next: XTI_UDP_RR, Prev: XTI_TCP_CC, Up: Options Common to TCP UDP and SCTP _RR tests 6.2.7 XTI_TCP_CRR ----------------- The XTI_TCP_CRR test is essentially the same as a *note TCP_CRR: TCP_CRR. test, only using the XTI rather than BSD Sockets interface. The test-specific options for an XTI_TCP_CRR test are the same as those for a TCP_RR test with the addition of the `-X ' option to specify the names of the local and/or remote XTI device file(s).  File: netperf.info, Node: XTI_UDP_RR, Next: DLCL_RR, Prev: XTI_TCP_CRR, Up: Options Common to TCP UDP and SCTP _RR tests 6.2.8 XTI_UDP_RR ---------------- An XTI_UDP_RR test is essentially the same as a UDP_RR test only using the XTI rather than BSD Sockets interface. It is requested by passing a value of "XTI_UDP_RR" to the `-t' global command-line option. The test-specific options for an XTI_UDP_RR test are the same as those for a UDP_RR test with the addition of the `-X ' option to specify the name of the local and/or remote XTI device file(s).  File: netperf.info, Node: DLCL_RR, Next: DLCO_RR, Prev: XTI_UDP_RR, Up: Options Common to TCP UDP and SCTP _RR tests 6.2.9 DLCL_RR -------------  File: netperf.info, Node: DLCO_RR, Next: SCTP_RR, Prev: DLCL_RR, Up: Options Common to TCP UDP and SCTP _RR tests 6.2.10 DLCO_RR --------------  File: netperf.info, Node: SCTP_RR, Prev: DLCO_RR, Up: Options Common to TCP UDP and SCTP _RR tests 6.2.11 SCTP_RR --------------  File: netperf.info, Node: Using Netperf to Measure Aggregate Performance, Next: Using Netperf to Measure Bidirectional Transfer, Prev: Using Netperf to Measure Request/Response, Up: Top 7 Using Netperf to Measure Aggregate Performance ************************************************ Ultimately, *note Netperf4: Netperf4. will be the preferred benchmark to use when one wants to measure aggregate performance because netperf has no support for explicit synchronization of concurrent tests. Until netperf4 is ready for prime time, one can make use of the heuristics and procedures mentioned here for the 85% solution. Basically, there are two ways to measure aggregate performance with netperf. The first is to run multiple, concurrent netperf tests and can be applied to any of the netperf tests. The second is to configure netperf with `--enable-burst' and is applicable to the TCP_RR test. * Menu: * Running Concurrent Netperf Tests:: * Using --enable-burst::  File: netperf.info, Node: Running Concurrent Netperf Tests, Next: Using --enable-burst, Prev: Using Netperf to Measure Aggregate Performance, Up: Using Netperf to Measure Aggregate Performance 7.1 Running Concurrent Netperf Tests ==================================== *note Netperf4: Netperf4. is the preferred benchmark to use when one wants to measure aggregate performance because netperf has no support for explicit synchronization of concurrent tests. This leaves netperf2 results vulnerable to "skew" errors. However, since there are times when netperf4 is unavailable it may be necessary to run netperf. The skew error can be minimized by making use of the confidence interval functionality. Then one simply launches multiple tests from the shell using a `for' loop or the like: for i in 1 2 3 4 do netperf -t TCP_STREAM -H tardy.cup.hp.com -i 10 -P 0 & done which will run four, concurrent *note TCP_STREAM: TCP_STREAM. tests from the system on which it is executed to tardy.cup.hp.com. Each concurrent netperf will iterate 10 times thanks to the `-i' option and will omit the test banners (option `-P') for brevity. The output looks something like this: 87380 16384 16384 10.03 235.15 87380 16384 16384 10.03 235.09 87380 16384 16384 10.03 235.38 87380 16384 16384 10.03 233.96 We can take the sum of the results and be reasonably confident that the aggregate performance was 940 Mbits/s. If you see warnings about netperf not achieving the confidence intervals, the best thing to do is to increase the number of iterations with `-i' and/or increase the run length of each iteration with `-l'. You can also enable local (`-c') and/or remote (`-C') CPU utilization: for i in 1 2 3 4 do netperf -t TCP_STREAM -H tardy.cup.hp.com -i 10 -P 0 -c -C & done 87380 16384 16384 10.03 235.47 3.67 5.09 10.226 14.180 87380 16384 16384 10.03 234.73 3.67 5.09 10.260 14.225 87380 16384 16384 10.03 234.64 3.67 5.10 10.263 14.231 87380 16384 16384 10.03 234.87 3.67 5.09 10.253 14.215 If the CPU utilizations reported for the same system are the same or very very close you can be reasonably confident that skew error is minimized. Presumeably one could then omit `-i' but that is not advised, particularly when/if the CPU utilization approaches 100 percent. In the example above we see that the CPU utilization on the local system remains the same for all four tests, and is only off by 0.01 out of 5.09 on the remote system. As the number of CPUs in the system increases, and so too the odds of saturating a single CPU, the accuracy of similar CPU utilization implying little skew error is diminished. This is also the case for those increasingly rare single CPU systems if the utilization is reported as 100% or very close to it. NOTE: It is very important to rememeber that netperf is calculating system-wide CPU utilization. When calculating the service demand (those last two columns in the output above) each netperf assumes it is the only thing running on the system. This means that for concurrent tests the service demands reported by netperf will be wrong. One has to compute service demands for concurrent tests by hand. If you wish you can add a unique, global `-B' option to each command line to append the given string to the output: for i in 1 2 3 4 do netperf -t TCP_STREAM -H tardy.cup.hp.com -B "this is test $i" -i 10 -P 0 & done 87380 16384 16384 10.03 234.90 this is test 4 87380 16384 16384 10.03 234.41 this is test 2 87380 16384 16384 10.03 235.26 this is test 1 87380 16384 16384 10.03 235.09 this is test 3 You will notice that the tests completed in an order other than they were started from the shell. This underscores why there is a threat of skew error and why netperf4 is the preferred tool for aggregate tests. Even if you see the Netperf Contributing Editor acting to the contrary!-) * Menu: * Issues in Running Concurrent Tests::  File: netperf.info, Node: Issues in Running Concurrent Tests, Prev: Running Concurrent Netperf Tests, Up: Running Concurrent Netperf Tests 7.1.1 Issues in Running Concurrent Tests ---------------------------------------- In addition to the aforementioned issue of skew error, there can be other issues to consider when running concurrent netperf tests. For example, when running concurrent tests over multiple interfaces, one is not always assured that the traffic one thinks went over a given interface actually did so. In particular, the Linux networking stack takes a particularly strong stance on its following the so called `weak end system model'. As such, it is willing to answer ARP requests for any of its local IP addresses on any of its interfaces. If multiple interfaces are connected to the same broadcast domain, then even if they are configured into separate IP subnets there is no a priori way of knowing which interface was actually used for which connection(s). This can be addressed by setting the `arp_ignore' sysctl before configuring interfaces. As it is quite important, we will repeat that it is very important to rememeber that each concurrent netperf instance is calculating system-wide CPU utilization. When calculating the service demand each netperf assumes it is the only thing running on the system. This means that for concurrent tests the service demands reported by netperf will be wrong. One has to compute service demands for concurrent tests by hand  File: netperf.info, Node: Using --enable-burst, Prev: Running Concurrent Netperf Tests, Up: Using Netperf to Measure Aggregate Performance 7.2 Using -enable-burst ======================= Starting in version 2.5.0 `--enable-burst=yes' is the default, which means one no longer must: configure --enable-burst To have burst-mode functionality present in netperf. This enables a test-specific `-b num' option in *note TCP_RR: TCP_RR, *note UDP_RR: UDP_RR. and *note omni: The Omni Tests. tests. Normally, netperf will attempt to ramp-up the number of outstanding requests to `num' plus one transactions in flight at one time. The ramp-up is to avoid transactions being smashed together into a smaller number of segments when the transport's congestion window (if any) is smaller at the time than what netperf wants to have outstanding at one time. If, however, the user specifies a negative value for `num' this ramp-up is bypassed and the burst of sends is made without consideration of transport congestion window. This burst-mode is used as an alternative to or even in conjunction with multiple-concurrent _RR tests and as a way to implement a single-connection, bidirectional bulk-transfer test. When run with just a single instance of netperf, increasing the burst size can determine the maximum number of transactions per second which can be serviced by a single process: for b in 0 1 2 4 8 16 32 do netperf -v 0 -t TCP_RR -B "-b $b" -H hpcpc108 -P 0 -- -b $b done 9457.59 -b 0 9975.37 -b 1 10000.61 -b 2 20084.47 -b 4 29965.31 -b 8 71929.27 -b 16 109718.17 -b 32 The global `-v' and `-P' options were used to minimize the output to the single figure of merit which in this case the transaction rate. The global `-B' option was used to more clearly label the output, and the test-specific `-b' option enabled by `--enable-burst' increase the number of transactions in flight at one time. Now, since the test-specific `-D' option was not specified to set TCP_NODELAY, the stack was free to "bundle" requests and/or responses into TCP segments as it saw fit, and since the default request and response size is one byte, there could have been some considerable bundling even in the absense of transport congestion window issues. If one wants to try to achieve a closer to one-to-one correspondence between a request and response and a TCP segment, add the test-specific `-D' option: for b in 0 1 2 4 8 16 32 do netperf -v 0 -t TCP_RR -B "-b $b -D" -H hpcpc108 -P 0 -- -b $b -D done 8695.12 -b 0 -D 19966.48 -b 1 -D 20691.07 -b 2 -D 49893.58 -b 4 -D 62057.31 -b 8 -D 108416.88 -b 16 -D 114411.66 -b 32 -D You can see that this has a rather large effect on the reported transaction rate. In this particular instance, the author believes it relates to interactions between the test and interrupt coalescing settings in the driver for the NICs used. NOTE: Even if you set the `-D' option that is still not a guarantee that each transaction is in its own TCP segments. You should get into the habit of verifying the relationship between the transaction rate and the packet rate via other means. You can also combine `--enable-burst' functionality with concurrent netperf tests. This would then be an "aggregate of aggregates" if you like: for i in 1 2 3 4 do netperf -H hpcpc108 -v 0 -P 0 -i 10 -B "aggregate $i -b 8 -D" -t TCP_RR -- -b 8 -D & done 46668.38 aggregate 4 -b 8 -D 44890.64 aggregate 2 -b 8 -D 45702.04 aggregate 1 -b 8 -D 46352.48 aggregate 3 -b 8 -D Since each netperf did hit the confidence intervals, we can be reasonably certain that the aggregate transaction per second rate was the sum of all four concurrent tests, or something just shy of 184,000 transactions per second. To get some idea if that was also the packet per second rate, we could bracket that `for' loop with something to gather statistics and run the results through beforeafter (ftp://ftp.cup.hp.com/dist/networking/tools): /usr/sbin/ethtool -S eth2 > before for i in 1 2 3 4 do netperf -H 192.168.2.108 -l 60 -v 0 -P 0 -B "aggregate $i -b 8 -D" -t TCP_RR -- -b 8 -D & done wait /usr/sbin/ethtool -S eth2 > after 52312.62 aggregate 2 -b 8 -D 50105.65 aggregate 4 -b 8 -D 50890.82 aggregate 1 -b 8 -D 50869.20 aggregate 3 -b 8 -D beforeafter before after > delta grep packets delta rx_packets: 12251544 tx_packets: 12251550 This example uses `ethtool' because the system being used is running Linux. Other platforms have other tools - for example HP-UX has lanadmin: lanadmin -g mibstats and of course one could instead use `netstat'. The `wait' is important because we are launching concurrent netperfs in the background. Without it, the second ethtool command would be run before the tests finished and perhaps even before the last of them got started! The sum of the reported transaction rates is 204178 over 60 seconds, which is a total of 12250680 transactions. Each transaction is the exchange of a request and a response, so we multiply that by 2 to arrive at 24501360. The sum of the ethtool stats is 24503094 packets which matches what netperf was reporting very well. Had the request or response size differed, we would need to know how it compared with the "MSS" for the connection. Just for grins, here is the excercise repeated, using `netstat' instead of `ethtool' netstat -s -t > before for i in 1 2 3 4 do netperf -l 60 -H 192.168.2.108 -v 0 -P 0 -B "aggregate $i -b 8 -D" -t TCP_RR -- -b 8 -D & done wait netstat -s -t > after 51305.88 aggregate 4 -b 8 -D 51847.73 aggregate 2 -b 8 -D 50648.19 aggregate 3 -b 8 -D 53605.86 aggregate 1 -b 8 -D beforeafter before after > delta grep segments delta 12445708 segments received 12445730 segments send out 1 segments retransmited 0 bad segments received. The sums are left as an excercise to the reader :) Things become considerably more complicated if there are non-trvial packet losses and/or retransmissions. Of course all this checking is unnecessary if the test is a UDP_RR test because UDP "never" aggregates multiple sends into the same UDP datagram, and there are no ACKnowledgements in UDP. The loss of a single request or response will not bring a "burst" UDP_RR test to a screeching halt, but it will reduce the number of transactions outstanding at any one time. A "burst" UDP_RR test will come to a halt if the sum of the lost requests and responses reaches the value specified in the test-specific `-b' option.  File: netperf.info, Node: Using Netperf to Measure Bidirectional Transfer, Next: The Omni Tests, Prev: Using Netperf to Measure Aggregate Performance, Up: Top 8 Using Netperf to Measure Bidirectional Transfer ************************************************* There are two ways to use netperf to measure the perfomance of bidirectional transfer. The first is to run concurrent netperf tests from the command line. The second is to configure netperf with `--enable-burst' and use a single instance of the *note TCP_RR: TCP_RR. test. While neither method is more "correct" than the other, each is doing so in different ways, and that has possible implications. For instance, using the concurrent netperf test mechanism means that multiple TCP connections and multiple processes are involved, whereas using the single instance of TCP_RR there is only one TCP connection and one process on each end. They may behave differently, especially on an MP system. * Menu: * Bidirectional Transfer with Concurrent Tests:: * Bidirectional Transfer with TCP_RR:: * Implications of Concurrent Tests vs Burst Request/Response::  File: netperf.info, Node: Bidirectional Transfer with Concurrent Tests, Next: Bidirectional Transfer with TCP_RR, Prev: Using Netperf to Measure Bidirectional Transfer, Up: Using Netperf to Measure Bidirectional Transfer 8.1 Bidirectional Transfer with Concurrent Tests ================================================ If we had two hosts Fred and Ethel, we could simply run a netperf *note TCP_STREAM: TCP_STREAM. test on Fred pointing at Ethel, and a concurrent netperf TCP_STREAM test on Ethel pointing at Fred, but since there are no mechanisms to synchronize netperf tests and we would be starting tests from two different systems, there is a considerable risk of skew error. Far better would be to run simultaneous TCP_STREAM and *note TCP_MAERTS: TCP_MAERTS. tests from just one system, using the concepts and procedures outlined in *note Running Concurrent Netperf Tests: Running Concurrent Netperf Tests. Here then is an example: for i in 1 do netperf -H 192.168.2.108 -t TCP_STREAM -B "outbound" -i 10 -P 0 -v 0 \ -- -s 256K -S 256K & netperf -H 192.168.2.108 -t TCP_MAERTS -B "inbound" -i 10 -P 0 -v 0 \ -- -s 256K -S 256K & done 892.66 outbound 891.34 inbound We have used a `for' loop in the shell with just one iteration because that will be much easier to get both tests started at more or less the same time than doing it by hand. The global `-P' and `-v' options are used because we aren't interested in anything other than the throughput, and the global `-B' option is used to tag each output so we know which was inbound and which outbound relative to the system on which we were running netperf. Of course that sense is switched on the system running netserver :) The use of the global `-i' option is explained in *note Running Concurrent Netperf Tests: Running Concurrent Netperf Tests. Beginning with version 2.5.0 we can accomplish a similar result with the *note the omni tests: The Omni Tests. and *note output selectors: Omni Output Selectors.: for i in 1 do netperf -H 192.168.1.3 -t omni -l 10 -P 0 -- \ -d stream -s 256K -S 256K -o throughput,direction & netperf -H 192.168.1.3 -t omni -l 10 -P 0 -- \ -d maerts -s 256K -S 256K -o throughput,direction & done 805.26,Receive 828.54,Send  File: netperf.info, Node: Bidirectional Transfer with TCP_RR, Next: Implications of Concurrent Tests vs Burst Request/Response, Prev: Bidirectional Transfer with Concurrent Tests, Up: Using Netperf to Measure Bidirectional Transfer 8.2 Bidirectional Transfer with TCP_RR ====================================== Starting with version 2.5.0 the `--enable-burst' configure option defaults to `yes', and starting some time before version 2.5.0 but after 2.4.0 the global `-f' option would affect the "throughput" reported by request/response tests. If one uses the test-specific `-b' option to have several "transactions" in flight at one time and the test-specific `-r' option to increase their size, the test looks more and more like a single-connection bidirectional transfer than a simple request/response test. So, putting it all together one can do something like: netperf -f m -t TCP_RR -H 192.168.1.3 -v 2 -- -b 6 -r 32K -S 256K -S 256K MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.1.3 (192.168.1.3) port 0 AF_INET : interval : first burst 6 Local /Remote Socket Size Request Resp. Elapsed Send Recv Size Size Time Throughput bytes Bytes bytes bytes secs. 10^6bits/sec 16384 87380 32768 32768 10.00 1821.30 524288 524288 Alignment Offset RoundTrip Trans Throughput Local Remote Local Remote Latency Rate 10^6bits/s Send Recv Send Recv usec/Tran per sec Outbound Inbound 8 0 0 0 2015.402 3473.252 910.492 910.492 to get a bidirectional bulk-throughput result. As one can see, the -v 2 output will include a number of interesting, related values. NOTE: The logic behind `--enable-burst' is very simple, and there are no calls to `poll()' or `select()' which means we want to make sure that the `send()' calls will never block, or we run the risk of deadlock with each side stuck trying to call `send()' and neither calling `recv()'. Fortunately, this is easily accomplished by setting a "large enough" socket buffer size with the test-specific `-s' and `-S' options. Presently this must be performed by the user. Future versions of netperf might attempt to do this automagically, but there are some issues to be worked-out.  File: netperf.info, Node: Implications of Concurrent Tests vs Burst Request/Response, Prev: Bidirectional Transfer with TCP_RR, Up: Using Netperf to Measure Bidirectional Transfer 8.3 Implications of Concurrent Tests vs Burst Request/Response ============================================================== There are perhaps subtle but important differences between using concurrent unidirectional tests vs a burst-mode request to measure bidirectional performance. Broadly speaking, a single "connection" or "flow" of traffic cannot make use of the services of more than one or two CPUs at either end. Whether one or two CPUs will be used processing a flow will depend on the specifics of the stack(s) involved and whether or not the global `-T' option has been used to bind netperf/netserver to specific CPUs. When using concurrent tests there will be two concurrent connections or flows, which means that upwards of four CPUs will be employed processing the packets (global `-T' used, no more than two if not), however, with just a single, bidirectional request/response test no more than two CPUs will be employed (only one if the global `-T' is not used). If there is a CPU bottleneck on either system this may result in rather different results between the two methods. Also, with a bidirectional request/response test there is something of a natural balance or synchronization between inbound and outbound - a response will not be sent until a request is received, and (once the burst level is reached) a subseqent request will not be sent until a response is received. This may mask favoritism in the NIC between inbound and outbound processing. With two concurrent unidirectional tests there is no such synchronization or balance and any favoritism in the NIC may be exposed.  File: netperf.info, Node: The Omni Tests, Next: Other Netperf Tests, Prev: Using Netperf to Measure Bidirectional Transfer, Up: Top 9 The Omni Tests **************** Beginning with version 2.5.0, netperf begins a migration to the `omni' tests or "Two routines to measure them all." The code for the omni tests can be found in `src/nettest_omni.c' and the goal is to make it easier for netperf to support multiple protocols and report a great many additional things about the systems under test. Additionally, a flexible output selection mechanism is present which allows the user to chose specifically what values she wishes to have reported and in what format. The omni tests are included by default in version 2.5.0. To disable them, one must: ./configure --enable-omni=no ... and remake netperf. Remaking netserver is optional because even in 2.5.0 it has "unmigrated" netserver side routines for the classic (eg `src/nettest_bsd.c') tests. * Menu: * Native Omni Tests:: * Migrated Tests:: * Omni Output Selection::  File: netperf.info, Node: Native Omni Tests, Next: Migrated Tests, Prev: The Omni Tests, Up: The Omni Tests 9.1 Native Omni Tests ===================== One access the omni tests "natively" by using a value of "OMNI" with the global `-t' test-selection option. This will then cause netperf to use the code in `src/nettest_omni.c' and in particular the test-specific options parser for the omni tests. The test-specific options for the omni tests are a superset of those for "classic" tests. The options added by the omni tests are: `-c' This explicitly declares that the test is to include connection establishment and tear-down as in either a TCP_CRR or TCP_CC test. `-d ' This option sets the direction of the test relative to the netperf process. As of version 2.5.0 one can use the following in a case-insenstive manner: `send, stream, transmit, xmit or 2' Any of which will cause netperf to send to the netserver. `recv, receive, maerts or 4' Any of which will cause netserver to send to netperf. `rr or 6' Either of which will cause a request/response test. Additionally, one can specify two directions separated by a '|' character and they will be OR'ed together. In this way one can use the "Send|Recv" that will be emitted by the *note DIRECTION: Omni Output Selectors. *note output selector: Omni Output Selection. when used with a request/reponse test. `-k [*note output selector: Omni Output Selection.]' This option sets the style of output to "keyval" where each line of output has the form: key=value For example: $ netperf -t omni -- -d rr -k "THROUGHPUT,THROUGHPUT_UNITS" OMNI TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost.localdomain (127.0.0.1) port 0 AF_INET : demo THROUGHPUT=59092.65 THROUGHPUT_UNITS=Trans/s Using the `-k' option will override any previous, test-specific `-o' or `-O' option. `-o [*note output selector: Omni Output Selection.]' This option sets the style of output to "CSV" where there will be one line of comma-separated values, preceeded by one line of column names unless the global `-P' option is used with a value of 0: $ netperf -t omni -- -d rr -o "THROUGHPUT,THROUGHPUT_UNITS" OMNI TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost.localdomain (127.0.0.1) port 0 AF_INET : demo Throughput,Throughput Units 60999.07,Trans/s Using the `-o' option will override any previous, test-specific `-k' or `-O' option. `-O [*note output selector: Omni Output Selection.]' This option sets the style of output to "human readable" which will look quite similar to classic netperf output: $ netperf -t omni -- -d rr -O "THROUGHPUT,THROUGHPUT_UNITS" OMNI TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost.localdomain (127.0.0.1) port 0 AF_INET : demo Throughput Throughput Units 60492.57 Trans/s Using the `-O' option will override any previous, test-specific `-k' or `-o' option. `-t' This option explicitly sets the socket type for the test's data connection. As of version 2.5.0 the known socket types include "stream" and "dgram" for SOCK_STREAM and SOCK_DGRAM respectively. `-T ' This option is used to explicitly set the protocol used for the test. It is case-insensitive. As of version 2.5.0 the protocols known to netperf include: `TCP' Select the Transmission Control Protocol `UDP' Select the User Datagram Procotol `SDP' Select the Sockets Direct Protocol `DCCP' Select the Datagram Congestion Control Protocol `SCTP' Select the Stream Control Transport Protocol `udplite' Select UDP Lite The default is implicit based on other settings. The omni tests also extend the interpretation of some of the classic, test-specific options for the BSD Sockets tests: `-m ' This can set the send size for either or both of the netperf and netserver sides of the test: -m 32K sets only the netperf-side send size to 32768 bytes, and or's-in transmit for the direction. This is effectively the same behaviour as for the classic tests. -m ,32K sets only the netserver side send size to 32768 bytes and or's-in receive for the direction. -m 16K,32K sets the netperf side send size to 16284 bytes, the netserver side send size to 32768 bytes and the direction will be "Send|Recv." `-M ' This can set the receive size for either or both of the netperf and netserver sides of the test: -M 32K sets only the netserver side receive size to 32768 bytes and or's-in send for the test direction. -M ,32K sets only the netperf side receive size to 32768 bytes and or's-in receive for the test direction. -M 16K,32K sets the netserver side receive size to 16384 bytes and the netperf side receive size to 32768 bytes and the direction will be "Send|Recv."  File: netperf.info, Node: Migrated Tests, Next: Omni Output Selection, Prev: Native Omni Tests, Up: The Omni Tests 9.2 Migrated Tests ================== As of version 2.5.0 several tests have been migrated to use the omni code in `src/nettest_omni.c' for the core of their testing. A migrated test retains all its previous output code and so should still "look and feel" just like a pre-2.5.0 test with one exception - the first line of the test banners will include the word "MIGRATED" at the beginning as in: $ netperf MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost.localdomain (127.0.0.1) port 0 AF_INET : demo Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 16384 16384 10.00 27175.27 The tests migrated in version 2.5.0 are: * TCP_STREAM * TCP_MAERTS * TCP_RR * TCP_CRR * UDP_STREAM * UDP_RR It is expected that future releases will have additional tests migrated to use the "omni" functionality. If one uses "omni-specific" test-specific options in conjunction with a migrated test, instead of using the classic output code, the new omni output code will be used. For example if one uses the `-k' test-specific option with a value of "MIN_LATENCY,MAX_LATENCY" with a migrated TCP_RR test one will see: $ netperf -t tcp_rr -- -k THROUGHPUT,THROUGHPUT_UNITS MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost.localdomain (127.0.0.1) port 0 AF_INET : demo THROUGHPUT=60074.74 THROUGHPUT_UNITS=Trans/s rather than: $ netperf -t tcp_rr MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost.localdomain (127.0.0.1) port 0 AF_INET : demo Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 16384 87380 1 1 10.00 59421.52 16384 87380  File: netperf.info, Node: Omni Output Selection, Prev: Migrated Tests, Up: The Omni Tests 9.3 Omni Output Selection ========================= The omni test-specific `-k', `-o' and `-O' options take an optional `output selector' by which the user can configure what values are reported. The output selector can take several forms: ``filename'' The output selections will be read from the named file. Within the file there can be up to four lines of comma-separated output selectors. This controls how many multi-line blocks of output are emitted when the `-O' option is used. This output, while not identical to "classic" netperf output, is inspired by it. Multiple lines have no effect for `-k' and `-o' options. Putting output selections in a file can be useful when the list of selections is long. `comma and/or semi-colon-separated list' The output selections will be parsed from a comma and/or semi-colon-separated list of output selectors. When the list is given to a `-O' option a semi-colon specifies a new output block should be started. Semi-colons have the same meaning as commas when used with the `-k' or `-o' options. Depending on the command interpreter being used, the semi-colon may have to be escaped somehow to keep it from being interpreted by the command interpreter. This can often be done by enclosing the entire list in quotes. `all' If the keyword all is specified it means that all known output values should be displayed at the end of the test. This can be a great deal of output. As of version 2.5.0 there are 157 different output selectors. `?' If a "?" is given as the output selection, the list of all known output selectors will be displayed and no test actually run. When passed to the `-O' option they will be listed one per line. Otherwise they will be listed as a comma-separated list. It may be necessary to protect the "?" from the command interpreter by escaping it or enclosing it in quotes. `no selector' If nothing is given to the `-k', `-o' or `-O' option then the code selects a default set of output selectors inspired by classic netperf output. The format will be the `human readable' format emitted by the test-specific `-O' option. The order of evaluation will first check for an output selection. If none is specified with the `-k', `-o' or `-O' option netperf will select a default based on the characterists of the test. If there is an output selection, the code will first check for `?', then check to see if it is the magic `all' keyword. After that it will check for either `,' or `;' in the selection and take that to mean it is a comma and/or semi-colon-separated list. If none of those checks match, netperf will then assume the output specification is a filename and attempt to open and parse the file. * Menu: * Omni Output Selectors::  File: netperf.info, Node: Omni Output Selectors, Prev: Omni Output Selection, Up: Omni Output Selection 9.3.1 Omni Output Selectors --------------------------- As of version 2.5.0 the output selectors are: `OUTPUT_NONE' This is essentially a null output. For `-k' output it will simply add a line that reads "OUTPUT_NONE=" to the output. For `-o' it will cause an empty "column" to be included. For `-O' output it will cause extra spaces to separate "real" output. `SOCKET_TYPE' This will cause the socket type (eg SOCK_STREAM, SOCK_DGRAM) for the data connection to be output. `PROTOCOL' This will cause the protocol used for the data connection to be displayed. `DIRECTION' This will display the data flow direction relative to the netperf process. Units: Send or Recv for a unidirectional bulk-transfer test, or Send|Recv for a request/response test. `ELAPSED_TIME' This will display the elapsed time in seconds for the test. `THROUGHPUT' This will display the througput for the test. Units: As requested via the global `-f' option and displayed by the THROUGHPUT_UNITS output selector. `THROUGHPUT_UNITS' This will display the units for what is displayed by the `THROUGHPUT' output selector. `LSS_SIZE_REQ' This will display the local (netperf) send socket buffer size (aka SO_SNDBUF) requested via the command line. Units: Bytes. `LSS_SIZE' This will display the local (netperf) send socket buffer size (SO_SNDBUF) immediately after the data connection socket was created. Peculiarities of different networking stacks may lead to this differing from the size requested via the command line. Units: Bytes. `LSS_SIZE_END' This will display the local (netperf) send socket buffer size (SO_SNDBUF) immediately before the data connection socket is closed. Peculiarities of different networking stacks may lead this to differ from the size requested via the command line and/or the size immediately after the data connection socket was created. Units: Bytes. `LSR_SIZE_REQ' This will display the local (netperf) receive socket buffer size (aka SO_RCVBUF) requested via the command line. Units: Bytes. `LSR_SIZE' This will display the local (netperf) receive socket buffer size (SO_RCVBUF) immediately after the data connection socket was created. Peculiarities of different networking stacks may lead to this differing from the size requested via the command line. Units: Bytes. `LSR_SIZE_END' This will display the local (netperf) receive socket buffer size (SO_RCVBUF) immediately before the data connection socket is closed. Peculiarities of different networking stacks may lead this to differ from the size requested via the command line and/or the size immediately after the data connection socket was created. Units: Bytes. `RSS_SIZE_REQ' This will display the remote (netserver) send socket buffer size (aka SO_SNDBUF) requested via the command line. Units: Bytes. `RSS_SIZE' This will display the remote (netserver) send socket buffer size (SO_SNDBUF) immediately after the data connection socket was created. Peculiarities of different networking stacks may lead to this differing from the size requested via the command line. Units: Bytes. `RSS_SIZE_END' This will display the remote (netserver) send socket buffer size (SO_SNDBUF) immediately before the data connection socket is closed. Peculiarities of different networking stacks may lead this to differ from the size requested via the command line and/or the size immediately after the data connection socket was created. Units: Bytes. `RSR_SIZE_REQ' This will display the remote (netserver) receive socket buffer size (aka SO_RCVBUF) requested via the command line. Units: Bytes. `RSR_SIZE' This will display the remote (netserver) receive socket buffer size (SO_RCVBUF) immediately after the data connection socket was created. Peculiarities of different networking stacks may lead to this differing from the size requested via the command line. Units: Bytes. `RSR_SIZE_END' This will display the remote (netserver) receive socket buffer size (SO_RCVBUF) immediately before the data connection socket is closed. Peculiarities of different networking stacks may lead this to differ from the size requested via the command line and/or the size immediately after the data connection socket was created. Units: Bytes. `LOCAL_SEND_SIZE' This will display the size of the buffers netperf passed in any "send" calls it made on the data connection for a non-request/response test. Units: Bytes. `LOCAL_RECV_SIZE' This will display the size of the buffers netperf passed in any "receive" calls it made on the data connection for a non-request/response test. Units: Bytes. `REMOTE_SEND_SIZE' This will display the size of the buffers netserver passed in any "send" calls it made on the data connection for a non-request/response test. Units: Bytes. `REMOTE_RECV_SIZE' This will display the size of the buffers netserver passed in any "receive" calls it made on the data connection for a non-request/response test. Units: Bytes. `REQUEST_SIZE' This will display the size of the requests netperf sent in a request-response test. Units: Bytes. `RESPONSE_SIZE' This will display the size of the responses netserver sent in a request-response test. Units: Bytes. `LOCAL_CPU_UTIL' This will display the overall CPU utilization during the test as measured by netperf. Units: 0 to 100 percent. `LOCAL_CPU_METHOD' This will display the method used by netperf to measure CPU utilization. Units: single character denoting method. `LOCAL_SD' This will display the service demand, or units of CPU consumed per unit of work, as measured by netperf. Units: microsconds of CPU consumed per either KB (K==1024) of data transferred or request/response transaction. `REMOTE_CPU_UTIL' This will display the overall CPU utilization during the test as measured by netserver. Units 0 to 100 percent. `REMOTE_CPU_METHOD' This will display the method used by netserver to measure CPU utilization. Units: single character denoting method. `REMOTE_SD' This will display the service demand, or units of CPU consumed per unit of work, as measured by netserver. Units: microseconds of CPU consumed consumed per either KB (K==1024) of data transferred or request/response transaction. `SD_UNITS' This will display the units for LOCAL_SD and REMOTE_SD `CONFIDENCE_LEVEL' This will display the confidence level requested by the user either explicitly via the global `-I' option, or implicitly via the global `-i' option. The value will be either 95 or 99 if confidence intervals have been requested or 0 if they were not. Units: Percent `CONFIDENCE_INTERVAL' This will display the width of the confidence interval requested either explicitly via the global `-I' option or implicitly via the global `-i' option. Units: Width in percent of mean value computed. A value of -1.0 means that confidence intervals were not requested. `CONFIDENCE_ITERATION' This will display the number of test iterations netperf undertook, perhaps while attempting to achieve the requested confidence interval and level. If confidence intervals were requested via the command line then the value will be between 3 and 30. If confidence intervals were not requested the value will be 1. Units: Iterations `THROUGHPUT_CONFID' This will display the width of the confidence interval actually achieved for `THROUGHPUT' during the test. Units: Width of interval as percentage of reported throughput value. `LOCAL_CPU_CONFID' This will display the width of the confidence interval actually achieved for overall CPU utilization on the system running netperf (`LOCAL_CPU_UTIL') during the test, if CPU utilization measurement was enabled. Units: Width of interval as percentage of reported CPU utilization. `REMOTE_CPU_CONFID' This will display the width of the confidence interval actually achieved for overall CPU utilization on the system running netserver (`REMOTE_CPU_UTIL') during the test, if CPU utilization measurement was enabled. Units: Width of interval as percentage of reported CPU utilization. `TRANSACTION_RATE' This will display the transaction rate in transactions per second for a request/response test even if the user has requested a throughput in units of bits or bytes per second via the global `-f' option. It is undefined for a non-request/response test. Units: Transactions per second. `RT_LATENCY' This will display the average round-trip latency for a request/response test, accounting for number of transactions in flight at one time. It is undefined for a non-request/response test. Units: Microseconds per transaction `BURST_SIZE' This will display the "burst size" or added transactions in flight in a request/response test as requested via a test-specific `-b' option. The number of transactions in flight at one time will be one greater than this value. It is undefined for a non-request/response test. Units: added Transactions in flight. `LOCAL_TRANSPORT_RETRANS' This will display the number of retransmissions experienced on the data connection during the test as determined by netperf. A value of -1 means the attempt to determine the number of retransmissions failed or the concept was not valid for the given protocol or the mechanism is not known for the platform. A value of -2 means it was not attempted. As of version 2.5.0 the meaning of values are in flux and subject to change. Units: number of retransmissions. `REMOTE_TRANSPORT_RETRANS' This will display the number of retransmissions experienced on the data connection during the test as determined by netserver. A value of -1 means the attempt to determine the number of retransmissions failed or the concept was not valid for the given protocol or the mechanism is not known for the platform. A value of -2 means it was not attempted. As of version 2.5.0 the meaning of values are in flux and subject to change. Units: number of retransmissions. `TRANSPORT_MSS' This will display the Maximum Segment Size (aka MSS) or its equivalent for the protocol being used during the test. A value of -1 means either the concept of an MSS did not apply to the protocol being used, or there was an error in retrieving it. Units: Bytes. `LOCAL_SEND_THROUGHPUT' The throughput as measured by netperf for the successful "send" calls it made on the data connection. Units: as requested via the global `-f' option and displayed via the `THROUGHPUT_UNITS' output selector. `LOCAL_RECV_THROUGHPUT' The throughput as measured by netperf for the successful "receive" calls it made on the data connection. Units: as requested via the global `-f' option and displayed via the `THROUGHPUT_UNITS' output selector. `REMOTE_SEND_THROUGHPUT' The throughput as measured by netserver for the successful "send" calls it made on the data connection. Units: as requested via the global `-f' option and displayed via the `THROUGHPUT_UNITS' output selector. `REMOTE_RECV_THROUGHPUT' The throughput as measured by netserver for the successful "receive" calls it made on the data connection. Units: as requested via the global `-f' option and displayed via the `THROUGHPUT_UNITS' output selector. `LOCAL_CPU_BIND' The CPU to which netperf was bound, if at all, during the test. A value of -1 means that netperf was not explicitly bound to a CPU during the test. Units: CPU ID `LOCAL_CPU_COUNT' The number of CPUs (cores, threads) detected by netperf. Units: CPU count. `LOCAL_CPU_PEAK_UTIL' The utilization of the CPU most heavily utilized during the test, as measured by netperf. This can be used to see if any one CPU of a multi-CPU system was saturated even though the overall CPU utilization as reported by `LOCAL_CPU_UTIL' was low. Units: 0 to 100% `LOCAL_CPU_PEAK_ID' The id of the CPU most heavily utilized during the test as determined by netperf. Units: CPU ID. `LOCAL_CPU_MODEL' Model information for the processor(s) present on the system running netperf. Assumes all processors in the system (as perceived by netperf) on which netperf is running are the same model. Units: Text `LOCAL_CPU_FREQUENCY' The frequency of the processor(s) on the system running netperf, at the time netperf made the call. Assumes that all processors present in the system running netperf are running at the same frequency. Units: MHz `REMOTE_CPU_BIND' The CPU to which netserver was bound, if at all, during the test. A value of -1 means that netperf was not explicitly bound to a CPU during the test. Units: CPU ID `REMOTE_CPU_COUNT' The number of CPUs (cores, threads) detected by netserver. Units: CPU count. `REMOTE_CPU_PEAK_UTIL' The utilization of the CPU most heavily utilized during the test, as measured by netserver. This can be used to see if any one CPU of a multi-CPU system was saturated even though the overall CPU utilization as reported by `REMOTE_CPU_UTIL' was low. Units: 0 to 100% `REMOTE_CPU_PEAK_ID' The id of the CPU most heavily utilized during the test as determined by netserver. Units: CPU ID. `REMOTE_CPU_MODEL' Model information for the processor(s) present on the system running netserver. Assumes all processors in the system (as perceived by netserver) on which netserver is running are the same model. Units: Text `REMOTE_CPU_FREQUENCY' The frequency of the processor(s) on the system running netserver, at the time netserver made the call. Assumes that all processors present in the system running netserver are running at the same frequency. Units: MHz `SOURCE_PORT' The port ID/service name to which the data socket created by netperf was bound. A value of 0 means the data socket was not explicitly bound to a port number. Units: ASCII text. `SOURCE_ADDR' The name/address to which the data socket created by netperf was bound. A value of 0.0.0.0 means the data socket was not explicitly bound to an address. Units: ASCII text. `SOURCE_FAMILY' The address family to which the data socket created by netperf was bound. A value of 0 means the data socket was not explicitly bound to a given address family. Units: ASCII text. `DEST_PORT' The port ID to which the data socket created by netserver was bound. A value of 0 means the data socket was not explicitly bound to a port number. Units: ASCII text. `DEST_ADDR' The name/address of the data socket created by netserver. Units: ASCII text. `DEST_FAMILY' The address family to which the data socket created by netserver was bound. A value of 0 means the data socket was not explicitly bound to a given address family. Units: ASCII text. `LOCAL_SEND_CALLS' The number of successful "send" calls made by netperf against its data socket. Units: Calls. `LOCAL_RECV_CALLS' The number of successful "receive" calls made by netperf against its data socket. Units: Calls. `LOCAL_BYTES_PER_RECV' The average number of bytes per "receive" call made by netperf against its data socket. Units: Bytes. `LOCAL_BYTES_PER_SEND' The average number of bytes per "send" call made by netperf against its data socket. Units: Bytes. `LOCAL_BYTES_SENT' The number of bytes successfully sent by netperf through its data socket. Units: Bytes. `LOCAL_BYTES_RECVD' The number of bytes successfully received by netperf through its data socket. Units: Bytes. `LOCAL_BYTES_XFERD' The sum of bytes sent and received by netperf through its data socket. Units: Bytes. `LOCAL_SEND_OFFSET' The offset from the alignment of the buffers passed by netperf in its "send" calls. Specified via the global `-o' option and defaults to 0. Units: Bytes. `LOCAL_RECV_OFFSET' The offset from the alignment of the buffers passed by netperf in its "receive" calls. Specified via the global `-o' option and defaults to 0. Units: Bytes. `LOCAL_SEND_ALIGN' The alignment of the buffers passed by netperf in its "send" calls as specified via the global `-a' option. Defaults to 8. Units: Bytes. `LOCAL_RECV_ALIGN' The alignment of the buffers passed by netperf in its "receive" calls as specified via the global `-a' option. Defaults to 8. Units: Bytes. `LOCAL_SEND_WIDTH' The "width" of the ring of buffers through which netperf cycles as it makes its "send" calls. Defaults to one more than the local send socket buffer size divided by the send size as determined at the time the data socket is created. Can be used to make netperf more processor data cache unfiendly. Units: number of buffers. `LOCAL_RECV_WIDTH' The "width" of the ring of buffers through which netperf cycles as it makes its "receive" calls. Defaults to one more than the local receive socket buffer size divided by the receive size as determined at the time the data socket is created. Can be used to make netperf more processor data cache unfiendly. Units: number of buffers. `LOCAL_SEND_DIRTY_COUNT' The number of bytes to "dirty" (write to) before netperf makes a "send" call. Specified via the global `-k' option, which requires that -enable-dirty=yes was specificed with the configure command prior to building netperf. Units: Bytes. `LOCAL_RECV_DIRTY_COUNT' The number of bytes to "dirty" (write to) before netperf makes a "recv" call. Specified via the global `-k' option which requires that -enable-dirty was specified with the configure command prior to building netperf. Units: Bytes. `LOCAL_RECV_CLEAN_COUNT' The number of bytes netperf should read "cleanly" before making a "receive" call. Specified via the global `-k' option which requires that -enable-dirty was specified with configure command prior to building netperf. Clean reads start were dirty writes ended. Units: Bytes. `LOCAL_NODELAY' Indicates whether or not setting the test protocol-specific "no delay" (eg TCP_NODELAY) option on the data socket used by netperf was requested by the test-specific `-D' option and successful. Units: 0 means no, 1 means yes. `LOCAL_CORK' Indicates whether or not TCP_CORK was set on the data socket used by netperf as requested via the test-specific `-C' option. 1 means yes, 0 means no/not applicable. `REMOTE_SEND_CALLS' `REMOTE_RECV_CALLS' `REMOTE_BYTES_PER_RECV' `REMOTE_BYTES_PER_SEND' `REMOTE_BYTES_SENT' `REMOTE_BYTES_RECVD' `REMOTE_BYTES_XFERD' `REMOTE_SEND_OFFSET' `REMOTE_RECV_OFFSET' `REMOTE_SEND_ALIGN' `REMOTE_RECV_ALIGN' `REMOTE_SEND_WIDTH' `REMOTE_RECV_WIDTH' `REMOTE_SEND_DIRTY_COUNT' `REMOTE_RECV_DIRTY_COUNT' `REMOTE_RECV_CLEAN_COUNT' `REMOTE_NODELAY' `REMOTE_CORK' These are all like their "LOCAL_" counterparts only for the netserver rather than netperf. `LOCAL_SYSNAME' The name of the OS (eg "Linux") running on the system on which netperf was running. Units: ASCII Text `LOCAL_SYSTEM_MODEL' The model name of the system on which netperf was running. Units: ASCII Text. `LOCAL_RELEASE' The release name/number of the OS running on the system on which netperf was running. Units: ASCII Text `LOCAL_VERSION' The version number of the OS running on the system on which netperf was running. Units: ASCII Text `LOCAL_MACHINE' The machine architecture of the machine on which netperf was running. Units: ASCII Text. `REMOTE_SYSNAME' `REMOTE_SYSTEM_MODEL' `REMOTE_RELEASE' `REMOTE_VERSION' `REMOTE_MACHINE' These are all like their "LOCAL_" counterparts only for the netserver rather than netperf. `LOCAL_INTERFACE_NAME' The name of the probable egress interface through which the data connection went on the system running netperf. Example: eth0. Units: ASCII Text. `LOCAL_INTERFACE_VENDOR' The vendor ID of the probable egress interface through which traffic on the data connection went on the system running netperf. Units: Hexadecimal IDs as might be found in a `pci.ids' file or at the PCI ID Repository (http://pciids.sourceforge.net/). `LOCAL_INTERFACE_DEVICE' The device ID of the probable egress interface through which traffic on the data connection went on the system running netperf. Units: Hexadecimal IDs as might be found in a `pci.ids' file or at the PCI ID Repository (http://pciids.sourceforge.net/). `LOCAL_INTERFACE_SUBVENDOR' The sub-vendor ID of the probable egress interface through which traffic on the the data connection went on the system running netperf. Units: Hexadecimal IDs as might be found in a `pci.ids' file or at the PCI ID Repository (http://pciids.sourceforge.net/). `LOCAL_INTERFACE_SUBDEVICE' The sub-device ID of the probable egress interface through which traffic on the data connection went on the system running netperf. Units: Hexadecimal IDs as might be found in a `pci.ids' file or at the PCI ID Repository (http://pciids.sourceforge.net/). `LOCAL_DRIVER_NAME' The name of the driver used for the probable egress interface through which traffic on the data connection went on the system running netperf. Units: ASCII Text. `LOCAL_DRIVER_VERSION' The version string for the driver used for the probable egress interface through which traffic on the data connection went on the system running netperf. Units: ASCII Text. `LOCAL_DRIVER_FIRMWARE' The firmware version for the driver used for the probable egress interface through which traffic on the data connection went on the system running netperf. Units: ASCII Text. `LOCAL_DRIVER_BUS' The bus address of the probable egress interface through which traffic on the data connection went on the system running netperf. Units: ASCII Text. `LOCAL_INTERFACE_SLOT' The slot ID of the probable egress interface through which traffic on the data connection went on the system running netperf. Units: ASCII Text. `REMOTE_INTERFACE_NAME' `REMOTE_INTERFACE_VENDOR' `REMOTE_INTERFACE_DEVICE' `REMOTE_INTERFACE_SUBVENDOR' `REMOTE_INTERFACE_SUBDEVICE' `REMOTE_DRIVER_NAME' `REMOTE_DRIVER_VERSION' `REMOTE_DRIVER_FIRMWARE' `REMOTE_DRIVER_BUS' `REMOTE_INTERFACE_SLOT' These are all like their "LOCAL_" counterparts only for the netserver rather than netperf. `LOCAL_INTERVAL_USECS' The interval at which bursts of operations (sends, receives, transactions) were attempted by netperf. Specified by the global `-w' option which requires -enable-intervals to have been specified with the configure command prior to building netperf. Units: Microseconds (though specified by default in milliseconds on the command line) `LOCAL_INTERVAL_BURST' The number of operations (sends, receives, transactions depending on the test) which were attempted by netperf each LOCAL_INTERVAL_USECS units of time. Specified by the global `-b' option which requires -enable-intervals to have been specified with the configure command prior to building netperf. Units: number of operations per burst. `REMOTE_INTERVAL_USECS' The interval at which bursts of operations (sends, receives, transactions) were attempted by netserver. Specified by the global `-w' option which requires -enable-intervals to have been specified with the configure command prior to building netperf. Units: Microseconds (though specified by default in milliseconds on the command line) `REMOTE_INTERVAL_BURST' The number of operations (sends, receives, transactions depending on the test) which were attempted by netperf each LOCAL_INTERVAL_USECS units of time. Specified by the global `-b' option which requires -enable-intervals to have been specified with the configure command prior to building netperf. Units: number of operations per burst. `LOCAL_SECURITY_TYPE_ID' `LOCAL_SECURITY_TYPE' `LOCAL_SECURITY_ENABLED_NUM' `LOCAL_SECURITY_ENABLED' `LOCAL_SECURITY_SPECIFIC' `REMOTE_SECURITY_TYPE_ID' `REMOTE_SECURITY_TYPE' `REMOTE_SECURITY_ENABLED_NUM' `REMOTE_SECURITY_ENABLED' `REMOTE_SECURITY_SPECIFIC' A bunch of stuff related to what sort of security mechanisms (eg SELINUX) were enabled on the systems during the test. `RESULT_BRAND' The string specified by the user with the global `-B' option. Units: ASCII Text. `UUID' The universally unique identifier associated with this test, either generated automagically by netperf, or passed to netperf via an omni test-specific `-u' option. Note: Future versions may make this a global command-line option. Units: ASCII Text. `MIN_LATENCY' The minimum "latency" or operation time (send, receive or request/response exchange depending on the test) as measured on the netperf side when the global `-j' option was specified. Units: Microseconds. `MAX_LATENCY' The maximum "latency" or operation time (send, receive or request/response exchange depending on the test) as measured on the netperf side when the global `-j' option was specified. Units: Microseconds. `P50_LATENCY' The 50th percentile value of "latency" or operation time (send, receive or request/response exchange depending on the test) as measured on the netperf side when the global `-j' option was specified. Units: Microseconds. `P90_LATENCY' The 90th percentile value of "latency" or operation time (send, receive or request/response exchange depending on the test) as measured on the netperf side when the global `-j' option was specified. Units: Microseconds. `P99_LATENCY' The 99th percentile value of "latency" or operation time (send, receive or request/response exchange depending on the test) as measured on the netperf side when the global `-j' option was specified. Units: Microseconds. `MEAN_LATENCY' The average "latency" or operation time (send, receive or request/response exchange depending on the test) as measured on the netperf side when the global `-j' option was specified. Units: Microseconds. `STDDEV_LATENCY' The standard deviation of "latency" or operation time (send, receive or request/response exchange depending on the test) as measured on the netperf side when the global `-j' option was specified. Units: Microseconds. `COMMAND_LINE' The full command line used when invoking netperf. Units: ASCII Text. `OUTPUT_END' While emitted with the list of output selectors, it is ignored when specified as an output selector.  File: netperf.info, Node: Other Netperf Tests, Next: Address Resolution, Prev: The Omni Tests, Up: Top 10 Other Netperf Tests ********************** Apart from the typical performance tests, netperf contains some tests which can be used to streamline measurements and reporting. These include CPU rate calibration (present) and host identification (future enhancement). * Menu: * CPU rate calibration:: * UUID Generation::  File: netperf.info, Node: CPU rate calibration, Next: UUID Generation, Prev: Other Netperf Tests, Up: Other Netperf Tests 10.1 CPU rate calibration ========================= Some of the CPU utilization measurement mechanisms of netperf work by comparing the rate at which some counter increments when the system is idle with the rate at which that same counter increments when the system is running a netperf test. The ratio of those rates is used to arrive at a CPU utilization percentage. This means that netperf must know the rate at which the counter increments when the system is presumed to be "idle." If it does not know the rate, netperf will measure it before starting a data transfer test. This calibration step takes 40 seconds for each of the local or remote ystems, and if repeated for each netperf test would make taking repeated measurements rather slow. Thus, the netperf CPU utilization options `-c' and and `-C' can take an optional calibration value. This value is used as the "idle rate" and the calibration step is not performed. To determine the idle rate, netperf can be used to run special tests which only report the value of the calibration - they are the LOC_CPU and REM_CPU tests. These return the calibration value for the local and remote system respectively. A common way to use these tests is to store their results into an environment variable and use that in subsequent netperf commands: LOC_RATE=`netperf -t LOC_CPU` REM_RATE=`netperf -H -t REM_CPU` netperf -H -c $LOC_RATE -C $REM_RATE ... -- ... ... netperf -H -c $LOC_RATE -C $REM_RATE ... -- ... If you are going to use netperf to measure aggregate results, it is important to use the LOC_CPU and REM_CPU tests to get the calibration values first to avoid issues with some of the aggregate netperf tests transferring data while others are "idle" and getting bogus calibration values. When running aggregate tests, it is very important to remember that any one instance of netperf does not know about the other instances of netperf. It will report global CPU utilization and will calculate service demand believing it was the only thing causing that CPU utilization. So, you can use the CPU utilization reported by netperf in an aggregate test, but you have to calculate service demands by hand.  File: netperf.info, Node: UUID Generation, Prev: CPU rate calibration, Up: Other Netperf Tests 10.2 UUID Generation ==================== Beginning with version 2.5.0 netperf can generate Universally Unique IDentifiers (UUIDs). This can be done explicitly via the "UUID" test: $ netperf -t UUID 2c8561ae-9ebd-11e0-a297-0f5bfa0349d0 In and of itself, this is not terribly useful, but used in conjuction with the test-specific `-u' option of an "omni" test to set the UUID emitted by the *note UUID: Omni Output Selectors. output selector, it can be used to tie-together the separate instances of an aggregate netperf test. Say, for instance if they were inserted into a database of some sort.  File: netperf.info, Node: Address Resolution, Next: Enhancing Netperf, Prev: Other Netperf Tests, Up: Top 11 Address Resolution ********************* Netperf versions 2.4.0 and later have merged IPv4 and IPv6 tests so the functionality of the tests in `src/nettest_ipv6.c' has been subsumed into the tests in `src/nettest_bsd.c' This has been accomplished in part by switching from `gethostbyname()'to `getaddrinfo()' exclusively. While it was theoretically possible to get multiple results for a hostname from `gethostbyname()' it was generally unlikely and netperf's ignoring of the second and later results was not much of an issue. Now with `getaddrinfo' and particularly with AF_UNSPEC it is increasingly likely that a given hostname will have multiple associated addresses. The `establish_control()' routine of `src/netlib.c' will indeed attempt to chose from among all the matching IP addresses when establishing the control connection. Netperf does not _really_ care if the control connection is IPv4 or IPv6 or even mixed on either end. However, the individual tests still ass-u-me that the first result in the address list is the one to be used. Whether or not this will turn-out to be an issue has yet to be determined. If you do run into problems with this, the easiest workaround is to specify IP addresses for the data connection explicitly in the test-specific `-H' and `-L' options. At some point, the netperf tests _may_ try to be more sophisticated in their parsing of returns from `getaddrinfo()' - straw-man patches to would of course be most welcome :) Netperf has leveraged code from other open-source projects with amenable licensing to provide a replacement `getaddrinfo()' call on those platforms where the `configure' script believes there is no native getaddrinfo call. As of this writing, the replacement `getaddrinfo()' as been tested on HP-UX 11.0 and then presumed to run elsewhere.  File: netperf.info, Node: Enhancing Netperf, Next: Netperf4, Prev: Address Resolution, Up: Top 12 Enhancing Netperf ******************** Netperf is constantly evolving. If you find you want to make enhancements to netperf, by all means do so. If you wish to add a new "suite" of tests to netperf the general idea is to: 1. Add files `src/nettest_mumble.c' and `src/nettest_mumble.h' where mumble is replaced with something meaningful for the test-suite. 2. Add support for an apropriate `--enable-mumble' option in `configure.ac'. 3. Edit `src/netperf.c', `netsh.c', and `netserver.c' as required, using #ifdef WANT_MUMBLE. 4. Compile and test However, with the addition of the "omni" tests in version 2.5.0 it is preferred that one attempt to make the necessary changes to `src/nettest_omni.c' rather than adding new source files, unless this would make the omni tests entirely too complicated. If you wish to submit your changes for possible inclusion into the mainline sources, please try to base your changes on the latest available sources. (*Note Getting Netperf Bits::.) and then send email describing the changes at a high level to or perhaps . If the concensus is positive, then sending context `diff' results to is the next step. From that point, it is a matter of pestering the Netperf Contributing Editor until he gets the changes incorporated :)  File: netperf.info, Node: Netperf4, Next: Concept Index, Prev: Enhancing Netperf, Up: Top 13 Netperf4 *********** Netperf4 is the shorthand name given to version 4.X.X of netperf. This is really a separate benchmark more than a newer version of netperf, but it is a decendant of netperf so the netperf name is kept. The facetious way to describe netperf4 is to say it is the egg-laying-woolly-milk-pig version of netperf :) The more respectful way to describe it is to say it is the version of netperf with support for synchronized, multiple-thread, multiple-test, multiple-system, network-oriented benchmarking. Netperf4 is still undergoing evolution. Those wishing to work with or on netperf4 are encouraged to join the netperf-dev (http://www.netperf.org/cgi-bin/mailman/listinfo/netperf-dev) mailing list and/or peruse the current sources (http://www.netperf.org/svn/netperf4/trunk).  File: netperf.info, Node: Concept Index, Next: Option Index, Prev: Netperf4, Up: Top Concept Index ************* [index] * Menu: * Aggregate Performance: Using Netperf to Measure Aggregate Performance. (line 6) * Bandwidth Limitation: Installing Netperf Bits. (line 64) * Connection Latency: TCP_CC. (line 6) * CPU Utilization: CPU Utilization. (line 6) * Design of Netperf: The Design of Netperf. (line 6) * Installation: Installing Netperf. (line 6) * Introduction: Introduction. (line 6) * Latency, Connection Establishment <1>: XTI_TCP_CRR. (line 6) * Latency, Connection Establishment <2>: XTI_TCP_CC. (line 6) * Latency, Connection Establishment <3>: TCP_CRR. (line 6) * Latency, Connection Establishment: TCP_CC. (line 6) * Latency, Request-Response <1>: SCTP_RR. (line 6) * Latency, Request-Response <2>: DLCO_RR. (line 6) * Latency, Request-Response <3>: DLCL_RR. (line 6) * Latency, Request-Response <4>: XTI_UDP_RR. (line 6) * Latency, Request-Response <5>: XTI_TCP_CRR. (line 6) * Latency, Request-Response <6>: XTI_TCP_RR. (line 6) * Latency, Request-Response <7>: UDP_RR. (line 6) * Latency, Request-Response <8>: TCP_CRR. (line 6) * Latency, Request-Response: TCP_RR. (line 6) * Limiting Bandwidth <1>: UDP_STREAM. (line 9) * Limiting Bandwidth: Installing Netperf Bits. (line 64) * Measuring Latency: TCP_RR. (line 6) * Packet Loss: UDP_RR. (line 6) * Port Reuse: TCP_CC. (line 13) * TIME_WAIT: TCP_CC. (line 13)  File: netperf.info, Node: Option Index, Prev: Concept Index, Up: Top Option Index ************ [index] * Menu: * --enable-burst, Configure: Using Netperf to Measure Aggregate Performance. (line 6) * --enable-cpuutil, Configure: Installing Netperf Bits. (line 24) * --enable-dlpi, Configure: Installing Netperf Bits. (line 30) * --enable-histogram, Configure: Installing Netperf Bits. (line 64) * --enable-intervals, Configure: Installing Netperf Bits. (line 64) * --enable-omni, Configure: Installing Netperf Bits. (line 36) * --enable-sctp, Configure: Installing Netperf Bits. (line 30) * --enable-unixdomain, Configure: Installing Netperf Bits. (line 30) * --enable-xti, Configure: Installing Netperf Bits. (line 30) * -4, Global: Global Options. (line 489) * -4, Test-specific <1>: Options Common to TCP UDP and SCTP _RR tests. (line 88) * -4, Test-specific: Options common to TCP UDP and SCTP tests. (line 110) * -6 Test-specific: Options Common to TCP UDP and SCTP _RR tests. (line 94) * -6, Global: Global Options. (line 498) * -6, Test-specific: Options common to TCP UDP and SCTP tests. (line 116) * -A, Global: Global Options. (line 18) * -a, Global: Global Options. (line 6) * -B, Global: Global Options. (line 29) * -b, Global: Global Options. (line 22) * -C, Global: Global Options. (line 42) * -c, Global: Global Options. (line 33) * -c, Test-specific: Native Omni Tests. (line 13) * -D, Global: Global Options. (line 56) * -d, Global: Global Options. (line 47) * -d, Test-specific: Native Omni Tests. (line 17) * -F, Global: Global Options. (line 76) * -f, Global: Global Options. (line 67) * -H, Global: Global Options. (line 95) * -h, Global: Global Options. (line 91) * -H, Test-specific: Options Common to TCP UDP and SCTP _RR tests. (line 17) * -h, Test-specific <1>: Options Common to TCP UDP and SCTP _RR tests. (line 10) * -h, Test-specific: Options common to TCP UDP and SCTP tests. (line 10) * -i, Global: Global Options. (line 179) * -I, Global: Global Options. (line 130) * -j, Global: Global Options. (line 205) * -k, Test-specific: Native Omni Tests. (line 37) * -L, Global: Global Options. (line 263) * -l, Global: Global Options. (line 242) * -L, Test-specific <1>: Options Common to TCP UDP and SCTP _RR tests. (line 26) * -L, Test-specific: Options common to TCP UDP and SCTP tests. (line 25) * -M, Test-specific: Options common to TCP UDP and SCTP tests. (line 48) * -m, Test-specific: Options common to TCP UDP and SCTP tests. (line 32) * -N, Global: Global Options. (line 293) * -n, Global: Global Options. (line 275) * -O, Global: Global Options. (line 338) * -o, Global: Global Options. (line 329) * -O, Test-specific: Native Omni Tests. (line 62) * -o, Test-specific: Native Omni Tests. (line 50) * -P, Global: Global Options. (line 363) * -p, Global: Global Options. (line 343) * -P, Test-specific <1>: Options Common to TCP UDP and SCTP _RR tests. (line 33) * -P, Test-specific: Options common to TCP UDP and SCTP tests. (line 61) * -r, Test-specific: Options Common to TCP UDP and SCTP _RR tests. (line 36) * -S Test-specific: Options common to TCP UDP and SCTP tests. (line 87) * -S, Global: Global Options. (line 381) * -s, Global: Global Options. (line 372) * -S, Test-specific: Options Common to TCP UDP and SCTP _RR tests. (line 68) * -s, Test-specific <1>: Options Common to TCP UDP and SCTP _RR tests. (line 48) * -s, Test-specific: Options common to TCP UDP and SCTP tests. (line 64) * -T, Global: Global Options. (line 423) * -t, Global: Global Options. (line 391) * -T, Test-specific: Native Omni Tests. (line 81) * -t, Test-specific: Native Omni Tests. (line 76) * -V, Global: Global Options. (line 468) * -v, Global: Global Options. (line 440) * -W, Global: Global Options. (line 480) * -w, Global: Global Options. (line 473)  Tag Table: Node: Top439 Node: Introduction1476 Node: Conventions4150 Node: Installing Netperf5913 Node: Getting Netperf Bits7467 Node: Installing Netperf Bits9326 Node: Verifying Installation17822 Node: The Design of Netperf18526 Node: CPU Utilization20122 Node: CPU Utilization in a Virtual Guest28845 Node: Global Command-line Options30432 Node: Command-line Options Syntax30971 Node: Global Options32367 Node: Using Netperf to Measure Bulk Data Transfer56521 Node: Issues in Bulk Transfer57194 Node: Options common to TCP UDP and SCTP tests61455 Node: TCP_STREAM67780 Node: TCP_MAERTS71864 Node: TCP_SENDFILE73101 Node: UDP_STREAM75601 Node: XTI_TCP_STREAM79037 Node: XTI_UDP_STREAM79682 Node: SCTP_STREAM80327 Node: DLCO_STREAM81027 Node: DLCL_STREAM83000 Node: STREAM_STREAM83874 Node: DG_STREAM84732 Node: Using Netperf to Measure Request/Response85413 Node: Issues in Request/Response87731 Node: Options Common to TCP UDP and SCTP _RR tests90104 Node: TCP_RR95128 Node: TCP_CC97528 Node: TCP_CRR99762 Node: UDP_RR100824 Node: XTI_TCP_RR103128 Node: XTI_TCP_CC103711 Node: XTI_TCP_CRR104216 Node: XTI_UDP_RR104728 Node: DLCL_RR105305 Node: DLCO_RR105458 Node: SCTP_RR105610 Node: Using Netperf to Measure Aggregate Performance105746 Node: Running Concurrent Netperf Tests106725 Node: Issues in Running Concurrent Tests110974 Node: Using --enable-burst112483 Node: Using Netperf to Measure Bidirectional Transfer119352 Node: Bidirectional Transfer with Concurrent Tests120483 Node: Bidirectional Transfer with TCP_RR122839 Node: Implications of Concurrent Tests vs Burst Request/Response125223 Node: The Omni Tests127036 Node: Native Omni Tests128083 Node: Migrated Tests133360 Node: Omni Output Selection135465 Node: Omni Output Selectors138446 Node: Other Netperf Tests166164 Node: CPU rate calibration166599 Node: UUID Generation168966 Node: Address Resolution169681 Node: Enhancing Netperf171657 Node: Netperf4173151 Node: Concept Index174055 Node: Option Index176381  End Tag Table 0707010003bb99000041ed0000000000000000000000024f45c9f100000000000000b500010002ffffffffffffffff0000001300000000root/usr/local/bin0707010003bb9a000081ed0000000000000000000000014f45c14a00030e88000000b500010002ffffffffffffffff0000001b00000000root/usr/local/bin/netperfELFR4 4 (44oX*X*X*X*@ ,,/usr/lib/ld.so.1  "$%'*,-./024689<=?@BCDEFHIKLNRSTWYZ[]^afhiklnopqsuvwxy{|}    !"#$&'(*+,./02345689;<>@ACDGJKNOPRTUVWYZ\`bcdefijklmprtuwxy{}~!#&()+1357:;>AGJMOPQUVX\_`bcdegjmrtz~  %)-17:=?BEFHILMQSX[]^_aghnoqsvz|,$QD'M >TOOdOTD@ dxCpw@z OL<< =.u p N"P)<8TQE`L YQh v<t-!} <`b (DT$# < L4QW4MaTNh x H.Q. 7  4- .*@.MSb vp Ma <0.x TM /   2M; z IDLP_`! rpx tP tO|C O.Ld-M-  /= 9` Lp ZjP.02 O.-dP@e (4O.L<TRE RЪ aNf^ n  tC{[ R # QhCL/bdQPr 0X?0d KTLVdHu$L{  .Vx-D Ps .CG: Md= p| }@N DR<<[q MM K$PL@3 N д , `5 CMB DPG # S  n MN!s ( J @<   4- az  K 8.4N" 0 2 )  D $OP P, [ l w -  = p. Q @WV  r - DN \ ' <* `XY 4 /? x O `c e  y DQ 2 P : CL PL   dN Q 1  P  TP  tQ X*1 p` = -D m Q $R0! ^ Oi Np p ~ P  < | P !  v> - Y  X.C NJ [ Of Ct $ <  <  @YY  O  g ' <! i  vL $N (.%>LCdRPN[4Lb u  4PD< W XA I R"WY 0 dLD 5\CL^Leo' s( 0Y X<K0~ <` pY DT<tNL -2P &<<.JQQRa t<ZM0 $M S P-$ 0 P m /=tM < M c7 ) =@JS~1>bRo9y~0|  pC pS{ | 8! @Rh wn T*<5а IQNc*  ZLbf MwO~0~ p6 к @DOX* .H.`^f _ -` 4Q;ЧV GQ<].wO0E `MtRDMR`. 8 P $ 7% K R00 \lr-n  v* lCO/9 *<O0 EN"4R/dM6Xy @4PQW k0w  w & 8 R   -H<   L&-=@-OM[Lbs* oA.vR, N@ 8<.dPx. m (8h.[P< p Nc.qNw$Y Pje @f P-Mi 2 PZ tL.([- /  MMpv \L# bQpz0p -PC`J Pn' P debug_DYNAMICfwriterem_dirty_countnst_to_hstcreate_data_socketprocessor_bindrecv_udp_streamloc_tcpcorkoptindrecv_request_ngai_strerrornetperf_requestsetitimerlocal_send_offsetcalculate_confidenceprint_sockets_usagemeasured_var_local_cpushutdown_controloutput_rowmemsetlistenwant_keepalivekstat_lookupHIST_get_percentileif_indextonamerecv_responsetest_len_tickslss_size_reqinterval_countloc_sndavoidnetperf_response_environlib_num_loc_cpusrecv_response_timed_nrsr_size_reqprint_top_test_headernetcpu_kstat10_idbreak_args_explicit_seprecv_tcp_streamkstat_opensigaddsetstat64local_data_portlib_elapsedmeasured_var_local_service_demandioctlmeasured_mean_local_timesend_udp_streamparse_socket_typemeasured_square_sum_resulttzset_defaultsmeasured_mean_local_cpumeasured_mean_local_service_demand__iobresponse_arraybreak_args_explicitsend_tcp_streamstrstrstop_timerfirst_burst_sizemeasured_sum_local_service_demandscan_cmd_lineremote_versionstrdupdi_initremote_data_familyremote_interval_usecsestablish_control__assertsend_responsefflushwait_time_secsget_rem_cpu_confidsend_requestsprintflib_remote_peak_cpu_idfind_egress_interface_by_linkconnectrem_tcpcorkfind_egress_interface_by_addrstrchrnetlib_idnetperf_idlocal_data_familycalc_service_demand_internaldisplay_confidenceformat_numberkeep_statisticsmeasured_sum_remote_service_demandget_uuid_stringgettimeofdayget_loc_cpu_confidlocal_sysnamemeasured_var_resultlocal_releaselsr_size_endlocal_machinelib_remote_maxrateconvertmsec_sleepresult_confidence_onlydump_globalsget_cpu_methodsendcatcherresolve_hosthtonditeration_minsysinfocalc_cpu_util_internalfind_system_infofreadrss_size_endhtonlprint_netserver_usagekstat_readusernamerequest_arrayhtonscalibrate_local_cpulocal_address_familynetlib_initstrcasecmpprint_headerslib_num_rem_cpus_exitbreak_argsHIST_newmeasured_square_sum_remote_cpuremote_send_widthlib_local_maxrateserver_sockerrnolib_local_cpu_utilcommand_linecpu_stopgetsocknamecalibrate_remote_cpunettest_sdpcpu_start_internalmeasured_local_resultsrecv_tcp_ccrecv_requestset_sockaddr_family_addr_portdi_prop_intsrouting_allowedrandom_ip_addressstrcmpHIST_clear__fpstarttoupperlib_use_idlescan_sockets_argsrecvparse_address_familydemo_intervalnettest_sctpatofsend_tcp_rrestablish_control_internalatoilocal_recv_aligncalc_thruput_intervallocal_recv_offsetlocal_test_port___Argvstart_itimeriteration_max_PROCEDURE_LINKAGE_TABLE_measured_square_sum_local_service_demandrecv_response_ncomplete_addrinfogetaddrinfoHIST_purgeconfidence_leveltest_transcontrol_familyremote_interval_burstcpu_startmeasured_sum_local_timedi_minor_namestop_itimerinterval_wateformat_cpu_methodmeasured_mean_resultfopen64recv_udp_rrnf_to_afinet_ttosno_controlsend_response_nget_local_system_infofind_interface_slotkstat_closecalc_thruput_omnibzeroidentify_localnettest_idsend_udp_rrunknownstrcpyrecvfromlibmainloc_dirty_countset_sock_bufferstrtodprogram__udiv64_GLOBAL_OFFSET_TABLE_start_timerlibfmtrem_cpu_ratedi_prop_namesetsockoptstrtokdump_addrinfostrtolrecv_tcp_maertsremote_connectedremote_sysname__ctypecalc_cpu_utilbind_to_specific_processor__environ_lockhst_to_strlib_remote_peak_cpu_utilmeasured_square_sum_remote_service_demandselect__fsr_init_valuegetsockoptmulticast_ttlHIST_get_statsremote_cpu_usagerecv_sizelsr_size_reqtest_nameinet_ftostime1gethrtimetime2calc_service_demand_fmtHIST_addrem_clean_countunlinkmeasured_var_remote_cpulib_local_peak_cpu_utilsranddi_walk_nodemkstemp64fprintfHIST_search_bucketrem_sndavoidgetoptremote_send_offsetnetlib_get_page_sizensec_type_to_strcalc_service_demand_get_exit_frame_monitornsec_enabled_to_strHIST_timestamp_start_xmknodset_hostname_and_portlocal_versionlsr_sizeremote_recv_alignatexitdump_responseremote_data_porthst_to_nstnetsh_ididentify_remotersp_sizesend_tcp_maertsaf_to_nfmeasured_fails_edataresult_brandshutdownsnprintfcpu_stop_internalremote_proc_affinityremote_recv_widthget_result_confidsendtodi_binding_namefind_interface_idsrss_size_reqfind_security_infosigactionacceptfind_driver_infoHIST_new_nget_remote_system_infoprotocol_to_strremote_data_addressset_port_numberreq_sizenetlib_init_cpu_maprecv_response_timed_lib_versionlss_sizenetperf_usage1di_prop_nextnetperf_usage2recv_tcp_conn_rrlss_size_endHIST_report__fsrretrieve_confident_valuestest_bytesloc_nodelaywheresmbios_closeverbosityunits_this_ticksend_request_nremote_machinedemo_unitscalibrate_idle_ratefreerecv_tcp_rrsysconfallocate_buffer_ring__xtolcalc_thruput_interval_omnifind_egress_interfaceloc_rcvavoid_etextmeasured_mean_remote_cpulib_remote_cpu_utilmeasured_sum_remote_cpuget_num_cpusinstall_signal_catchersget_idmemcmpuuid_createtest_timerem_nodelaymeasured_mean_remote_timefreeaddrinfolib_cpu_mapcmd_filenetperf_versionsum_rowlib_local_peak_cpu_idmallocdi_finialarmsmbios_openmeasured_mean_remote_service_demandremote_releasersr_sizecpu_util_terminateprint_netperf_usagesnpuidinit_statconfidence_iterationsmeasured_sum_resultlocal_cpu_ratesend_tcp_conn_rrloc_clean_countset_nonblockrsr_size_endpowlocal_data_addresslocal_connectedsqrtdelta_microlocal_send_aligntimes_updi_prop_typegetpidinet_ptoslocal_cpu_usagecallocsendfile_tcp_streamsend_tcp_cc__1cG__CrunMdo_exit_code6F_v_HIST_timestamp_stop_addrem_rcvavoidlib_local_per_cpu_utilcpu_util_initnetlib_controlremote_recv_offsetparse_protocolHIST_timestampmemcpymeasured_sum_local_cpu__longdouble_usedsigemptysetperrorformat_unitsoptargsmbios_info_commonrss_sizesend_sizecomplete_addrinfosstrlenget_sock_buffershell_num_cpusmeasured_var_local_timegetprotobynamemeasured_square_sum_local_timeloc_cpu_ratelocal_host_namemeasured_var_remote_service_demandcpu_binding_requestedfcntldemo_modeinet_ntoninet_ntopalloc_sendfile_buf_ringconvert_timespecsendfilev64remote_cpu_ratemeasured_square_sum_local_cpurewindaccess_buffercalc_thruputntohd_nunamerand32get_sockaddr_family_addr_portkeep_histogramntohldi_minor_nextfill_fileremote_send_alignparse_directionlocal_proc_affinityntohsdump_requeststrncpysend_tcp_msslibsocket.so.1SUNW_1.4libnsl.so.1SUNW_1.7libkstat.so.1SUNW_0.7libsmbios.so.1SUNWprivate_1.1libdevinfo.so.1SUNW_1.1libsendfile.so.1libm.so.2libc.so.1 '=  '=  (=  qN +; '= KT '= Ke '= Ko'= KqN +<-8P{ d*h*l*p*t*x*I|****Y***&***w**0**2***v*B**;**<**>*G*t*[*******+++%+ +++++l +$+(+,+0+4+g8+a<+@+D+PH+ L+nP+^T+X+\\+`+d+Sh+l+p+t+ x+|+++M++|++++++4+,+++)+++y++/+W+i+++u+++-+D++++i,,u,r ,w,,O,5\*%`*%d*h%h*h%l*h%p*h%t*h %x*h(%|*h0%*h8p%*h@`%*hHP%*hP@%*hX0%*h` %*hh%*hp%*hx%*h%*h%*h%*h%*h%*h%*h%*hp%*h`%*hP%*h@%*h0%*h %*h%*h%*h%*h%*h%*h%*h%*h %*h(%*h0%+h8p%+h@`%+hHP% +hP@%+hX0%+h` %+hh%+hp% +hx%$+h%(+h%,+h%0+h%4+h%8+h%<+h%@+hp%D+h`%H+hP%L+h@%P+h0%T+h %X+h%\+h%`+h%d+h%h+h%l+h%p+h%t+h %x+h(%|+h0%+h8p%+h@`%+hHP%+hP@%+hX0%+h` %+hh%+hp%+hx%+h%+h%+h%+h%+h%+h%+h%+hp%+h`%+hP%+h@%+h0%+h %+h%+h%+h%+h%+h%+h%+h%+h %+h(%+h0%,h8p%,h@`%,hHP% ,hP@%,hX0%,h` %,hhjjR,th8-t<-t PE-u T-RU 4-RPwPjURQt`|$уD- D$td$у`tƒ 3fd$f T$tfd$f L$l$YZ]U5dE PEPsgt y\ t&hhh jh/u(PhhXPhh=6hhujh'hhujh艝hheujh ~hh9ujhѯRh h ujh&h(hujhh0hujh}0h8hujhAhDh]ujhEyhLh5u [hThu ;jh\jhjhjj~/uhEEUjjEPE PEPjEEÐUjEPEEÐUjEPcEEÐUjj UEEÐU EEEEEPEPj# tjhjjsÐU<EA E5,E)8EDEE@w$WEèWWWWU$E)TE\EEtԃt吋EÐU0lEAxE5E)EE} tÃttِEÐULEaEUEIjjEPhj hE!E}tɐt=t뺐EÐU0EAE5E)EE}t吃tǃt؋EÐUE|jE PEP EuEaE|jE PEP E=E)|EEptِEÐUjjuuEEE EEEE EjEPUEjEPDEEE8EDEE+EU@DU+UEBE@EE~ȋEEEEEÐUjjuEEE EEEE EEE8EDEE+EU@DU+UEBE@EE~jEP^EjEPMEEEEEEÐU]6/XEE]ÐU ]BE@EEj@PEE غH BEE |E ~/h PjPjjEj@PeEEЋ]#,#E ؉]E%=tjEP>ЋEPE@EEEE | E =~/hHPjPHjjEEUEjPȋUE EU +ЉUE s EEE EEEv EE EEEEغH BEUEMы##E ؋UEUEjPȋUE E@EE+WE@PhP jP%jjE@p뮐]ÐUjjEE=~jjPhhtPjPjjhhjxP -xll-R ӋlPDžp<DžtjpPjjxPhst>jjPhhtPjPjjjjjEPEP-P$hÐUE tEE EEjjjEPjjÐUhjEP EEÐUE} E@ EEE@v;~*EPhP jPE@~EPhP -EE;E}2UjP.ȋU E@EE;E|Ρ~MEPhPP Ujjhhh|PjPjjjhh-P=tjhGjjÐU-jjzÐU E} E@ EEE@v;~*EPhP* jPZE@~"jjEPj@hP`EE;E}2UjPȋU E@EE;E|Ρ~IhPjjhhh,PcjPjjjhh-PEE=t2jhLEPhpP jjÐUjjdÐU EEE} E@ EEE@v;~*EPhPj jPE@EEEEE;EtqjjjEPEP-PEE~JEEEEEEE+EEE;Et'jjjEPEP-PqEEEE;E}2UjPqȋU E@EE;E|Ρt'EPhPd jPEu>jjPhhtP*jPZjjEuKt#hPjPj-PEE;E}B~EPhP jPjjq~--tj-PEEEÐUjjQEEÐUTEEEEEEE } E@ E EE@v;~*EPh4P jPE@EE@sU衘E@EE@rhjdP -dXX-R ӋXPEx\Dž`j\PjjdPhSEEt-jjEPPh|PjjE;EtqjjjEPEP-PEE~JEEEEEEE+EEE;Et'jjjEPEP-PEEt'EPhP jP!EE;E}2U衘jPȋU衘 E@EE;E|΋Eujh)jj}E;E}@EPhh_ jh~jj5~TÐUjEPÐUjjÐUEPjÐUX jj)EEEPhUEEtjEP|jh4|EPjEEtjEPX8jhL@8EPjEEtjEPTjhdTEPjEEtjEPjh|Rjh4|jhL8jhdxTjh|dÐUhPPhP ÐUE u EEEEEjEPEPEPhEP|}XE u E EjjPEPhP9jPiE@tQE u<E DEEjj@PEPhPjPÐU E u EEEEEjjEPEPhEPy}[E u E EjjPEPhLP%jPUjj ~LE u E EjjEPEPh|PjPEPE PEP ÐU ]u}E EjEPjPEPEPhEPXEHE@tE@E HE}Ej@PREj@P_؋Ej@ PЋEjj@PRSVGPEPhEP(E@EEE@jPPhPEP EEU;PsRE@uhE lEEE@PEPEP< E@EEU;PrhtEPE@EEjEP6]u}ÐU4]̡tjP jjPPhPkjPJt>jPjjPPhlPjPOE@EEuEEE@EjEPENE@-jEPLjEP>EtCjjE PEPhPjP-EEEE]ÐU]EPEPEPEPE PEP--ucjEP=jEP-jjPE PEPSEPEPhP(jPjj]U jP}jhjjmjjPPPPPhjPhE(EEEÐUeEhPEPh P ÐU$E"t%jh(1jj腿hDPrEPhP[ ÐUhhEtNlEx,ÐU Et ,hh;}@BH+E+EE]EE]E]E E  PÐUdEhEd d]d d d]t5l]t t5l]t t t5l]DEHEvdEhEb-g}$K} GJЃKM뼃m}gvk9룐mCxzEuu]EÐU $E PEP]E]EÐUdEhEKd d]3d d d]t5l]t t5l]t t t5l]DEHE-PhP jP$dEhEg-g}$K} G뤃KM됃m}gFk tmxJ]Euu]EÐU $E PEP`]E]EÐUjEP]E]EE=}IEz"v EE`E@EE=|EEEÐU tDEEjE P$$EPEPhPC(jPsE uE Ez u EEz uDEEuE]E uE ]E]E]tTEEjEPEPEPEPE P$$EPEPhPl8jP蜹E]E]EÐUdEhEEPEPEPE PEPEPEP]E]EÐU-xuDEHEdEhEEPEPEPE PEPEPEP]E]EÐULEzv E.]Ej j]EEEÐU [jj(t]E]0jhEPt jhhH` EEEÐUEEEЋ ȍ++ʋU+ы ȍ++ʉMjEPjjjj讹EEt/u E#jh萷jjEEÐUjh 蒸EEujhHjj蜶jEPEU@ E jP6ЋE E ujh޶jj2EEEUjjAEEÐUEEdUEUEDŽUEDŽ UEDŽUEDŽ@UEDŽUEDŽ` UEDŽ E@EEdiEǀ Eǀ Eǀ U  Eǀ Eǀ Eǀ Eǀ Eǀ Eǀ Eǀ ÐUEǀ Eǀ Eǀ ÐU ]E E uEU EU E U@ E U E t:]E jjPP$誷]E܃ Eݘ E ;E }E EE EEU􉐔 E ;E ~E EE EEU E ]E]EzsE U@ Ez7s5E]EM]EЋEEE@U@BsE5]Ez=s;E]EM]E藶ЋEEE@U@BE5]Ez=s;E]EM]E?ЋE EE@U@BE5]Ez=s;E]EM]EЋEEE@U@BmE5]Ez=s;E]EM]E菵ЋE@EE@U@BE5]Ez=s;E]EM]E7ЋEEE@U@BE5]Ez9s7E]EM]EߴЋE` EE@U@BhE5]Ez9s7E]EM]E苴ЋE EE@U@BE U@ ]UE E PhPs EE }kEEEEE@EU;}%UEM ME@EE@EU;|ۋEPhP E@EE |htPÐU EEEd}UEM ME@EEd|EEEÐUEPhh EPhh E Ph(h EPh8h E@PhHhn EPhXhS E` Phhh8 E Phxh E PhP蔯 E PhPw ÐU]E EEdEU@BEMUXEXE@;E |EEEU +PUEEU@+BEEME]E藱EE@EEd|EE]ÐUEۀ M ]EFEEEEu EHPDPEPEPEPEPEEt EEUPPEPEPEPPEEt EEUPPEPEPEP PYEEt EEGUxPtPEPEPEPPEEt EEUPPEPEPEP@PEEt EEUPPEPEPEPPEEt EEUPPEPEPEP` PYEEt EEJUPPEPEPEP PEEt EE EEÐUEU BEU BE Eۀ Eۀ EXUEۀ ܊ Eۀ jjPP$}w]mEEۀ jjPP$}@]mEEXUBPBP;]E웋EX&UBBUBBÐUʋUBJÐUE UH@+JBEEEEU;Eu/hP跪jPjj蛩EU ; uhPtUE jP0E U@ EM ‹ЋE E U@ ÐU;Eu/hPjPjj˨EU ; uGUEjj P PhHP茩jP輨jjpEj P9UE E PP2PEPE U@ EM ‹ЋE E UH ÐU졔------------... ..... .$.(.,.0.4.8.<.@.D.H.L.P.T.X.\.`.d.h.l.p.t.x.|....... .U8   $ ($,(0,4084<8@`BPBPMݝL݅L]EPEP菁ݝL݅L]4u<\4ٝLمL$8ٝLمL]ٝLمLٝLمLjj$$EPEP贄ٝLمL]1ٝLمL]ٝLمL]<tW`@EٝLمL`j@PEP$EPEP!ٝLمL].ٝLمL]ٝLمL]_ٝLمL]ٝLمL]ٝLمL]ٝLمL]jjEPEPEPEPEPEPEPpEP@(pE@pE.zspE;pE;nEPEPEPEPEPEP诠.zs~虡4u<jxPbtE`j@P{buE4tZu T<u\ T<\EtE\PR$EPPa<Zu T<u\ T<\EuE\PR$EPP<t,btEuEjPRQEPP;u T<u\ T<\EEEEE\P$$$$EPEP$,PPPEPP;;Hw$u T<u\ T<\j\PEPEPEPP:tyaPEPP: u T<uX T<XEܛXPEPEP$,PPPEPP3:(w$EЉLۅLy-0ݝL݅LE`@LۅLy-0ݝL݅LE`j@P$EP$EPEPH<P<<PPPhhhEPPQ9HEPEPP;9 jPk8DHHUL t#hP8jP7t#hP8jP7 t#hLPY8jP7t-@ Ph|P"8 jPR7@<@<@@@$@@(j@8P费Ћjj@4PRPP=j@8PyjjjPPPP5jPu;djj6@u%~ @$u'=@$$u $@$jj@PB PP$PdPt#hPU6jP5jP:u,jP7(cjj5DžPPP9 u,jP7bjj4jP9ЋPٝمX@t=@ j@P{ٝمX@ PP@P@P P$PaDžPPPx8 ujPF6jjZ3@ jPGj@PsDžjjjPBPPr5u`jj2ۅ܅ݝ@@u:jjjPBPP4gjP4u`jj1PBPrtOjjPPhP2PhP2 jP1PPg@ݝ݅XP PxPP@t7ٝم$uٝمXtgh P1jPPPhTP1PhPq1 jP0u^jP+3jP3ÐUL t#hP0jP0t#hP0jP/_t#hPs0jP/t-@ Ph0P<0 jPl/t#h\P0jP?/@<@<@@@$@@(j@8P衱Ћjj@4PRPP*j@8PfjjjPPPP"jP{u(\jj.@u"~ , ,@,u'=,@u @jj@PB P,PPTHt#hPE.jPu-jP1u,jP/[jj,DžPPP1 u,jP/Zjj,jP 1ЋPٝمX@t=@ j@PsٝمX@ PP@P@P P$,PYDžj@ P?j@PlPPP@0 ujP.jj"+DžDžjjj,PBPP-;,t3} uYXjjt*ۅ܅ݝ@@WjP,u+Xjj*jjj,PBPP,PBPjtOjjPPhP*PhP* jP)PPU8ݝ݅XP P@t7ٝم$mٝمXtghP)jPPPh0P)PhP}) jP(xPPcVjP+jP+ÐU$`EEEEEEEELE܍E؍Eԍ EEDžlDžh xtpjjjEPEP|PLt|PEPh z EEpE*.zs pE;|pE;F EEEEEDžlDžhu $u $Eu'jj<<PP<PP$AEEu'jj@<P(P<P$P@EjEPDEEujh ~&jj%thH P&4t"jPmٝLمL/= x<Px<PxPxH<P x0PxD<Px<Px<Px<P x<P$xP(x8P0xP4txP,ڋxP,jh(%ЋxP8|j@P輧ЋxP<~hp P(%P'XthpP$t@t@t@<t@<t@t@P|PQPhPh$ jh #jP#jj=#||@PBPEP& ujh #jj"t$EjP>7Ej4PYcptj<Poxptt E<l;hl;<t)j<PhPlPh P#Ujjj<PBPEP$EċE;<tjh r"jj!l@l<~ l;h}l;<NUjjj<PBPEP@$EċE;<t>t uE~jh( !jj$!E@El@l<EE@EE~wjjjEPEPEP{#EEtEu0u E7jhH D!jj E+EEEEEEE@ElHlh;<}@h@ht)jlP<PhPhh P!ẼtIptHtt~#hP jPj<Pu<P<Pu;h},j<PWu<P<Pcu;h|ԡ<<<<<<ptE@EEtEHE~9Edƒu'EPh P jP]EQEP4P_/uRu"th8P|QPhPT jh jPujj)<E<U‰LۅL]EٝLمLuݝ@݅@]4u<h4ٝ@م@$bٝ@م@]E ٝ@م@ٝ@م@jj$$$cٝ@م@].ٝ@م@]ٝ@م@]<t_p@EE ٝ@م@pj@PEP$$fcٝ@م@]/ٝ@م@]ٝ@م@]_ٝ@م@]ٝ@م@]ٝ@م@]ٝ@م@]jjEPEPEPEPEPEPEPpEP{(pE@pEjEP.zspE;pE;EPEPEPEPEPEP.zs~π4u<jxPAtEpj@PAuE\4tZu T<u d T<dEtEdPR$EPPZu T<u d T<dEuEdPR$EPP=tb-xu*tEuEjjPREPP.AtEuEjPRQEPP-xuE`EdJ<<@ۅ@MjjPP$\ݝ@݅@ݝ`u T<u \T<\EEEEE\P$$$$dP`P$<P<PPPEPPLjjPPEPPw$77-xuE`EdJ<<@ۅ@MjjPP$S[ݝ@݅@ݝ`u T<u \T<\j\PdP`PEPPdt>-xuEX EXJ?PXPPk -xuETEXJ<<@ۅ@MjjPP$?Zݝ@݅@ݝTu T<u PT<PEțPPXPTP$<P<PPPEPP,jjPPEPPew$ 76-xu m-<~ <d Džd=u d@@ۅ@<MjjPP$۽4Xݝ@ۭ4݅@<MjjPP$۽4۽(Xݝ@ۭ4ۭ(݅@$Ƀ$EPEP$H<P<<PH<PPSEPP<$ 1113T4T4U Ex E E E E E |xtjjjEPEPEPvtEPEPh8觩 EpE^lEEEEE.zs pE;|pE;EEEjEPEEujhX7jj,uH~4=}p Džpp, ,u  Eu'jj<<PP,PP-E4t"jPXZٝlمl/u|<P|,P|<P|P |H<P|<P|P|P |8P$|P(jh(Ћ|P,Ej@P\Ћ|P0I>Eu"thpP(jh6jjx@PEPx@x@x@<tjUE@PBPEP ujhjj.t#hPjPtjP%$hPjPj4P$Qptj<P:fpt<t%Ujjj,PBPEPE-MUE@PBPj,PAPEPEE;,tLE} u'=u E@EjhD@jjE@EE@EptHtt~#hP@jPpj<Pd<P<Pe;h},j<Pd<P<Pd;h|ԡ<<<<<<pt\EP4P|O/Bu th`PV&jhjj.t@E,E䉅dۅdy-0ݝd݅d]E],Edۅdy-0ݝd݅d]EPEP{Pݝd݅d]EPEP[Pݝd݅d]4u<\4ٝdمd$Rٝdمd]ٝdمdٝdمdjj$$EPEPSٝdمd]̛1ٝdمd]ٝdمd]̛<tWt@ Eٝdمdtj@PEP$EPEPRٝdمd]ț.ٝdمd]ٝdمd]ț_ٝdمd]ٝdمd]ٝdمd]ٝdمd]țjjEPEPEPEPEPEPEPpEP k(EEEEEEEE܉EEE]pE@pEjEP.zspE;pE;EPEPEPEPEPEPHopEUH+EpEUH+EpEUH+EܡpEHdۅdE].zs~o4u<\jxP0tEtj@P0uE4t*E̛tEjP$EPP (EțtEjP$EPP t,a1tEuEjPRQEPPq EEEEEEț$$EPEPEP$P$$EPEPEPEP$,PPEPP `w$CjjEPEPEPP tm0PEPP EE؛jjEPEPEP$PEPEPEPEP$,PPEPP: Hw$CjPVB`B`B0CTCTCUDDžDžDž t#hPjP~#hPbjP~#hP+jP[~-@ PhP jP$$u $jj@PB PAP$P!E~#h@PjP~#hxPSjP@<@$@@(@<j@0PЋjj@,PRPP|j@0P踈jjjPPPPtEjEPӖu3jj[@ B DžPPP u,jP3jjjP_ ЋPٝمX@@t7@j@PKٝمX@@ PP@PP2j@PDjP6t#hPjP< DžUPPjPBPPh;t0u%t91jj@E@EPPPQ u,jP0jjt#hPjP<t,UjjjPBPP*UjjjPBPP,;t5u%t/jj'@E@E:t*PhP jPPBPNBtمٝt0م$hPjPD‰t*PhHP jPjPzЋPPPxPP@t*jP EٝمX ٝمX ~#hhPjP-jPU`EEEEEEELEE܍E؍ EEEjjjEPEPEP+tEPEPh\ EEEEpEV.zs pE;|pE;l EEEu $u $EЃu'jj<<PP<PPEЋẼu'jj@<P(P<P$PEjEP2EEujhljjth,P4t"jPEٝlمl/E<PE<PEPEH<P E0PED<PE<PE<PE<P$EP(E8P0EP4tEP,ڋEP,jh(ЋEP8Ej@PЋEP<~hTPX(W0uethpP'E@E@E@<E@E@PEPpQPhP jhMjPjjUE@PBPEP ujh jjWt&EjPEj4P;ptj<PPptEE;<}ZUjjj<PBPEPEȋE;<tjh3jjE@EE;<|t EUjjj<PBPEPEȋE;<t*ujhjjEЋ@EЋUjjj<PBPEPEE;<t*ukjhTjjE̋@E̡ptHtt~#hP[jPj<PO<P<P#O;h},j<PN<P<PN;h|ԡ<<<<<<ptE@EċEtEHE~9EĹdƒu'EPh P jPEEP4P29/u@,u"th8PQPhP jhyjP jj<Eċ<U‰EEٝlمluݝ`݅`]4u<d4ٝ`م`$(<ٝ`م`]E ٝ`م`ٝ`م`jj$$$=ٝ`م`].ٝ`م`]ٝ`م`]<t[E@EE ٝ`م`Ej@PEP$$ =ٝ`م`]1ٝ`م`]ٝ`م`]_ٝ`م`]ٝ`م`]ٝ`م`]ٝ`م`]jjEPEPEPEPEPEPEPpEP(U(pE@pEjEPC.zspE;pE;EPEPEPEPEPEPY.zs~sZ4u<jxPntEEj@PXuEG4tVu T<uE T<EEtEEPR$EPPCRu T<u E T<EEuEEPR$EPPtb-xu*tEuEjjPREPP.ktEuEjPRQEPP{-xuEEEEI<<`ۅ`MjjPP$S6ݝ`݅`]u T<u| T<|EEEEE|P$$$$EPEP$<P<PPPEPPLjjPPEPP_w$\'-xuEEEEI<<`ۅ`MjjPP$5ݝ`݅`]u T<u| T<|j|PEPEPEPPbt>-xuEx ExPxPP7 -xuEtExJ<<`ۅ`MjjPP$ 4ݝ`݅`ݝtu T<upT<pEԛpPxPtP$<P<PPPEPPS,jjPPEPP1w$\jPN~hW X XYZZUD t#h PjPt#h0PpjPt#h\P9jPitfjj@ PBPhPjj@PBPhPjPu $u $jj@ PBPAP$PM Ejj@PBPAPP Et#hPjP>t#h,PjP@<@<@0@@4j@rt#hP<jPljj DžPPP uYjPt#hPjPjjjP ЋPt-@Ph PV jPٝمX@$t7@j@(PlٝمXPP@P@PP Džj@$P @,~.Dž@,jP@,؉DžtPPP ubuDžPh4P jPjPMjjat#h\PDjPt@jjjPPPyu9uDžxjj?~)+ 7u>t(h@PjPLjjj@PPPuXu3DžhHPjPcjjx@t Ht*PhP/ jP_jPPB$Ptمٝt*PhP jP@BЋPPP @$t'jP ٝمXt#hPjP!ÐU`Ex EEEE EEEXEEE EEEjjjEPEPEPFOtEPEPhwZ EEEth,P4t"jP? ٝ|م|,E<PE<PEPEH<P E0PED<PE<PE<PE<P E<P$EP(E8P0EP4tEP,ڋEP,jh(RЋEP8Ej@P%GЋEP<~hTPE@E@E@<E@<E@E@PEPPtHhpPjEPOPhP jPPPhP jhIjPjjjP=+=t&U =+ =‹=‰E =EEHEt#EjPyEj4Pt Eă!E@EE;=|=EjEPMU;uE@Et#E̹dƒuEPhXEPEPNjEPREȋEȃujhjj(UE@PBPEP~ EEuuuE;jh |jEPLPEPh jEPLPhjjjjjEPEPEPEEunE@E̋EătEHEġ~=jEP7LjjPEPhPjPLjEP0u E6jhxjj̿EăEP4Pu"th8PtQPhPL jh(ݿjPmjj!<E̋<U‰|ۅ|]EPEPݝt݅t]4u<94z8u6hPP苿hPxjP訾ٝtمt$3ٝtمt]E ٝtمtٝtمtjj$$$ٝtمt]1ٝtمt]ٝtمt]<z8u6hPohP\jP茽E@EE ٝtمtEj@PEP$$ٝtمt]/ٝtمt]ٝtمt]4tE$EPP虽E$EPP{t&tEuEjjPREPPCEEٝtمtuݝh݅hEEEE$$$$$$<P<PPPEPPǼHjjPPEPP襼w$Eٝhمhuݝh݅h$EPPLtPEPP% EEٝhمhuݝh݅h$$<P<PPPEPPͻ(jjPPEPP諻w$~*H<P<<PH<PPEPPbHUHDž t#h,PjP#t#hPPƺjP-t#h|P菺jP迹jhP@EEuhPh胹jjGtfjj@ PBPhPjj@PBPhPjPUP@HJ#Ћ@ ‰UP@HJ#Ћ@‰t#h PbjP蒸t#hL P5jPe@<@<@ @@0@@4j@jEPDP; EEu9jh*ЋEPE @jDP߈E@xEE@tEEEPh$*u$Ej@ P袄ЋEPE+EPh,*΄uEU @ BEE0EEEEHEE{Eujh8*-ЋEPEu E @jDPÐU4j%EPh E̋Ẽt`hH*EPbEhH*jPEЋEЃtjEP藃ЋEPjEP}ЋEPjhL*dЋEPÐU(jjEPjhjxE;EujEP)TEPhEPV E؋E؃ujEPЋEPjEPjEP'ÐUjEPREPE PUE@E @jhT*aЋEPUWVS[M_[^_UWVS[1_[^_?netperfnetperfXXXXXX@ @@@resolve_host.A@@ A$@Y@j@cAxi)@ʡE6@~jt @h|?5@ rh@~jt@Q@ r@jt@m@S㥛@;On@HzG@)\(@?5^I @(\@zG@+@X9v@㥛 @p= ף@d;O@Zd;O@Pn@{Gz@ r@"~j@Mb@\(\@tV@jtO@#@w/]@"~j@T㥛 @- @ˡE @ףp= @ @'1Z @ +@q= ףp@jt@7A`@~jt@|?5^@v/@/$@S@(\@S@Zd;O@~jt@K7A`@K@Zd;@^I +@v@?5^I @@?Y@?create_data_socket{Gz??@.AO_@?@ @?Y@PGO_@?@remotehost is %s and port %s TCP_STREAMTCP_MAERTSTCP_MSSTCP_SENDFILETCP_RRTCP_CRRTCP_CCUDP_STREAMUDP_RRLOC_CPUREM_CPUThe test you requested is unknown to this netperf. Please verify that you have the correct test name, and that test family has been compiled into this netperf. netperf: setitimerUnknownDisabledPermissiveEnforcingUNKNOWN MODESELinuxUNKNOWN TYPESOCK_DGRAMSOCK_STREAMSOCK_SEQPACKETSOCK_UNKNOWNIPPROTO_TCPIPPROTO_UDPIPPROTO_SCTPIPPROTO_UNKNOWN(%d)AF_INETAF_INET6AF_INET_SDPAF_UNSPECMask length must be between 0 and 32 inclusive for AF_INET Mask length must be between 0 and 128 inclusive for AF_INET Unexpected Address Family of %u Sorry, this system has more CPUs (%d) than I can handle (%d). Please alter MAXCPUS in netlib.h and recompile. netperf: caught SIGINT catcher: timer popped with times_up != 0 installing catcher for all signals Could not install signal catcher for sig %d, errno %d About to start a timer for %d seconds. start_timer: error installing alarm handler errno %d error starting alarm timer, ret %d errno %d setting the interval timer to %d sec %d usec test len %d ticks UnknownSystemUnknownReleaseUnknownVersionUnknownMachine2.5.0netlib_init: request_array at %p netlib_init: response_array at %p KMGkmgusrCould not open requested fill filewidth >= 1netlib.cmalloc(%u) failed! malloc(%d) failed! This was here to try to avoid dead-code elimination %d allocate_sendfile_buf_ring: incomplete writealloc_sendfile_buf_ring: could not allocate temp namealloc_sendfile_buf_ring: could not allocate buffer for filealloc_sendfile_buf_ring: Could not open requested filealloc_sendfile_buf_ring: could not stat filealloc_sendfile_buf_ring: specified file too small. file must be larger than send_width * send_size request contents: %d: %8x %8x %8x %8x |%4.4s| |%4.4s| |%4.4s| |%4.4s| response contents %d: %8x %8x %8x %8x >%4.4s< >%4.4s< >%4.4s< >%4.4s< %-7.2fKBytesMBytesGBytes10^3bits10^6bits10^9bitsTransshutdown_control: shutdown of control connection requested. %s errno %d shutdown_control: error in shutdownshutdown_control: no response receivedWARNING, htonl conversion count of %d was larger than netperf_request entered send_request_n...contents before %d htonls: send_request_n...contents after %d htonls: send_request: about to send %u bytes from %p send_request: send call failuresend_response_n: contents of %u ints before %d htonl, send_response_n: contents after htonl about to send %u bytes from %p send_response_n: send call failureBytesSent: %d recv_request: received %d bytes of request. recv_request: error on recvrecv_request: remote requested shutdown of control recv_request: partial request received of %d bytes WARNING, htonl conversion count of %d was larger than netperf_response netperf: receive_response: no response received. errno %d counter %d recv_response: received a %d byte response recv_responserecv_response: partial response received: %d bytes UnknownRemoteSysnameUnknownRemoteReleaseUnknownRemoteMachineUnknownRemoteVersionhello world debug: %d netperf: get_sock_buffer: getsockopt %s: errno %d SO_SNDBUFSO_RCVBUFnetperf: get_sock_buffer: %s socket size determined to be %d sendreceivenetperf: set_sock_buffer: %s option: errno %d netperf: set_sock_buffer: %s of %d requested. getaddrinfo returned the following for host '%s' port '%s' family %s cannonical name: '%s' flags: %x family: %s: socktype: %s protocol %s addrlen %d (nil) sa_family: %s sadata: %d %.2x resolve_host called with host '%s' port '%s' family %s Sleeping on getaddrinfo EAI_AGAIN %s: could not resolve host '%s' port '%s' af %s getaddrinfo returned %d %s establish_control called with host '%s' port '%s' remfam %s local '%s' port '%s' locfam %s establish_control: unable to allocate control socketbound control socket to %s and %s successful connection to remote netserver at %s and %s establish_control: connect failed, errno %d %s trying next address combination establish_control: bind failed, errno %d %s trying next address combination establish control: are you sure there is a netserver listening on %s at port %s? establish_control could not establish the control connection from %s port %s address family %s to %s port %s address family %s identify_local: uname%-15s%-15s%-15s%-15s%-15sLocal Information Sysname Nodename Release Version Machine %s identify_remote: on remoteRemote Information Sysname Nodename Release Version Machine %sWARNING calc_throughput_internal_omni: unknown units %c calc_service_demand called: units_sent = %f elapsed_time = %f cpu_util = %f num cpu = %d calc_service_demand using: units_sent = %f elapsed_time = %f cpu_util = %f num cpu = %d calc_service_demand got: thruput = %f servdem = %f msec_sleep: selectHIST_new_n - histogram_struct malloc failedHIST_new_n - time_ones malloc failed: %4dUNIT_USEC TEN_USEC HUNDRED_USEC UNIT_MSEC TEN_MSEC HUNDRED_MSEC UNIT_SEC TEN_SEC >100_SECS: %d HIST_TOTAL: %d HIST_timestamp_start called with NULL histogram HIST_timestamp_start called with full time_ones HIST_timestamp_stop called with NULL histogram HIST_timestamp_stop called with empty time_ones consumer %d producer %d calculate_confidence: itr %d; time %f; res %f lcpu %f; rcpu %f lsdm %f; rsdm %f Conf_itvl %2d: results:%4.1f%% loc_cpu:%4.1f%% rem_cpu:%4.1f%% !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : %4.3f%% !!! Local CPU util : %4.3f%% !!! Remote CPU util : %4.3f%% Attempting to parse address family from %s derived from %s 6inet4unspec0WARNING! %s not recognized as an address family, using AF_UNPSEC Are you sure netperf was configured for that address family? Attempting to parse socket type from %s derived from %s streamdgramxmitsendtransmitrecvreceivemaertsrrAttempting to parse protocol from %s derived from %s tcpudpsctpTCP_STREAM12865%s%s%smalloc() to store program name failed! malloc(%d) failed! A:a:b:B:CcdDf:F:H:hi:I:jk:K:l:L:n:NO:o:P:p:rSs:t:T:v:VW:w:46Sorry, Demo Mode not configured into this netperf. Please consider reconfiguring netperf with --enable-demo=yes and recompiling Only 95%% and 99%% confidence level is supported I don't know how to get dirty. Unable to malloc space for result brand Netperf version %s 2.5.0localhost::1Netperf does not understand %d as an address family Netperf could not resolve %s as a host name 0.0.0.0::0TCP_MAERTSTCP_RRTCP_CRRUDP_STREAMUDP_RRTCP_SENDFILETCP_CCTCP_MSSomniRRRrrRProgram name: %s Local send alignment: %d Local recv alignment: %d Remote send alignment: %d Remote recv alignment: %d Report local CPU %d Report remote CPU %d Verbosity: %d Debug: %d Port: %s Test name: %s Test bytes: %d Test time: %d Test trans: %d Host name: %s StreamDatagramSeqpacketUnknownTCPUDPSCTPIP DefaultUnknown Protocoltcpnetperf: get_tcp_info: getsockopt TCP_MAXSEG: errno %d complete_addrinfo using hostname %s port %s family %s type %s prot %s flags 0x%x Sleeping on getaddrinfo EAI_AGAIN complete_addrinfo: could not resolve '%s' port '%s' af %d getaddrinfo returned %d %s WARNING! Changed bogus getaddrinfo socket type %d to %d WARNING! Changed bogus getaddrinfo protocol %d to %d WARNING! getaddrinfo returned a socket type which did not match the requested type. Please contact your vendor for a fix to this bug in getaddrinfo() WARNING! getaddrinfo returned a protocol other than the requested protocol. Please contact your vendor for a fix to this bug in getaddrinfo() WARNING! getaddrinfo on this platform does not accept IPPROTO_SCTP! Please contact your vendor for a fix to this bug in getaddrinfo(). WARNING! getaddrinfo on this platform does not accept IPPROTO_DCCP! Please contact your vendor for a fix to this bug in getaddrinfo(). local_data_address not set, using local_host_name of '%s' local_data_address not set, using address family info 0.0.0.0::0what to put here?%uGiven Unexpected Address Family of %u UNKN FAMILYset_port_number Unexpected Address Family of %u set_sockaddr_family_addr_port Unexpected Address Family of %u get_sockaddr_family_addr_port family mismatch %d vs %d get_sockaddr_family_addr_port: Unexpected Address Family of %u netperf: create_data_socket: socket: errno %d fam %s type %s prot %s errmsg %s create_data_socket: socket %d obtained... netperf: create_data_socket: nodelay: errno %d netperf: create_data_socket: [TCP|SCTP]_NODELAY requested... %s: unable to set SO_KEEPALIVE on data socket: %s (errno %d) netperf: create_data_socket: SO_REUSEADDR failed %d netperf: create_data_socket: data socket bind failed errno %d port: %d netperf: create_data_socket: so_dontroute: errno %d we never expected to get here in get_address_address %s from %s (%s) port %u %s to %s (%s) port %u %s : +/-%.3f%% @ %2d%% conf. %s on result only : nodelay : copy avoidance : no control : spin intervalREQUEST/RESPONSE : first burst %d : cpu bind Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. %s/sec %7.2f %s %6d %6d %6d %-6.2f %7.2f %s Recv Send Send Utilization Service Demand Socket Socket Message Elapsed Send Recv Send Recv Size Size Size Time Throughput local remote local remote bytes bytes bytes secs. %-8.8s/s %% %c %% %c us/KB us/KB %6.3f %c %s %6d %6d %6d %-6.2f %7.2f %-6.2f %-6.2f %-6.3f %-6.3f %s Alignment Offset %-8.8s %-8.8s Sends %-8.8s Recvs Local Remote Local Remote Xfered Per Per Send Recv Send Recv Send (avg) Recv (avg) %5d %5d %5d %5d %6.4g %6.2f %6d %6.2f %6d Maximum Segment Size (bytes) %6d TCP STREAM TESTnetperf: send_tcp_stream: tcp stream data socketsend_tcp_stream: send_socket obtained... netperf: send_tcp_stream: requesting TCP stream test remote listen done. netperf: remote error %dnetperf: send_tcp_stream: data socket connect failednetperf: data send errorlen was %d about to spin suspend netperf: cannot shutdown tcp stream socketremote reporting results for %.2f seconds BytesRecv Send Send Utilization Service Demand Socket Socket Message Elapsed Recv Send Recv Send Size Size Size Time Throughput local remote local remote bytes bytes bytes secs. %-8.8s/s %% %c %% %c us/KB us/KB Alignment Offset %-8.8s %-8.8s Recvs %-8.8s Sends Local Remote Local Remote Xfered Per Per Recv Send Recv Send Recv (avg) Send (avg) %5d %5d %5d %5d %6.4g %6.2f %6d %6.2f %6d TCP MAERTS TESTnetperf: send_tcp_maerts: tcp stream data socketsend_tcp_maerts: recv_socket obtained... netperf: send_tcp_maerts: requesting TCP maerts test netperf: send_tcp_maerts: data socket connect failednetperf: send_tcp_maerts: test must be timed send_tcp_maerts: data recv errornetperf: cannot shutdown tcp maerts socketremote results obtained Maximum Segment Size (bytes) %d %s TCP MSS TESTnetperf: send_tcp_mss: requesting TCP stream test netperf: send_tcp_mss: data socket connect failedTCP SENDFILE TESTnetperf: sendfile_tcp_stream: tcp stream data socketsendfile_tcp_stream: send_socket obtained... netperf: data send error: sendfilelen was %d send_size was %d netserver: recv_tcp_stream: entered... recv_tcp_stream: setting the response type... recv_tcp_stream: the response type is set... recv_tcp_stream: requested alignment of %d recv_tcp_stream: receive alignment and offset set... recv_tcp_stream: got %g bytes recv_tcp_stream: got %d recvs recv_tcp_stream: test complete, sending results. bytes_received %g receive_calls %d len %d netserver: recv_tcp_maerts: entered... recv_tcp_maerts: setting the response type... recv_tcp_maerts: the response type is set... recv_tcp_maerts: requested alignment of %d recv_tcp_maerts: grabbing a socket... recv_tcp_maerts: receive alignment and offset set... recv_tcp_maerts: got %g bytes recv_tcp_maerts: got %d sends recv_tcp_maerts: test complete, sending results. bytes_sent %g send_calls %d Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec Local /Remote Socket Size Request Resp. Elapsed Send Recv Size Size Time Throughput bytes Bytes bytes bytes secs. %s/sec %-6d %-6d %-6d %-6d %-6.2f %7.2f %s %-6d %-6d Local /Remote Socket Size Request Resp. Elapsed Trans. CPU CPU S.dem S.dem Send Recv Size Size Time Rate local remote local remote bytes bytes bytes bytes secs. per sec %% %c %% %c us/Tr us/Tr Local /Remote Socket Size Request Resp. Elapsed Tput CPU CPU S.dem S.dem Send Recv Size Size Time %-8.8s local remote local remote bytes bytes bytes bytes secs. per sec %% %c %% %c us/Tr us/Tr Local /Remote Socket Size Request Resp. Elapsed Latency CPU CPU S.dem S.dem Send Recv Size Size Time usecs local remote local remote bytes bytes bytes bytes secs. per tran %% %c %% %c us/Tr us/Tr %-6d %-6d %-6d %-6d %-6.2f %-6.2f %-6.2f %-6.2f %-6.3f %-6.3f %s Alignment Offset RoundTrip Trans Throughput Local Remote Local Remote Latency Rate %-8.8s/s Send Recv Send Recv usec/Tran per sec Outbound Inbound %5d %5d %5d %5d %-6.3f %-6.3f %-6.3f %-6.3f TCP REQUEST/RESPONSE TESTnetperf: send_tcp_rr: tcp stream data socketsend_tcp_rr: send_socket obtained... netperf: send_tcp_rr: requesting TCP rr test netperf: data socket connect failedinjecting, req_outstndng %d req_cwnd %d burst %d send_tcp_rr: initial burst data send errorsend_tcp_rr: data send errorsend_tcp_rr: data recv errorincr req_cwnd to %d first_burst %d reqs_outstndng %d Transaction %d completed Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # %s/sec %7.2f %6d %6d %-7.2f %7d %6d %7.2f %6d %-7.2f %7d %7.2f Socket Message Elapsed Messages CPU Service Size Size Time Okay Errors Throughput Util Demand bytes bytes secs # # %s/sec %% %c%c us/KB %6.2f %c %6d %6d %-7.2f %7d %6d %7.1f %-6.2f %-6.3f %6d %-7.2f %7d %7.1f %-6.2f %-6.3f UDP UNIDIRECTIONAL SEND TESTudp_send: data socketsend_udp_stream: remote data connection done. send_udp_stream: error on remotesend_udp_stream: data socket connect failedsend_udp_stream: connected data socket. Sorry, UDP_STREAM tests must be timed. udp_send: data send errorsend_udp_stream: remote results obtained netserver: recv_udp_stream: entered... recv_udp_stream: setting the response type... recv_udp_stream: the response type is set... recv_udp_stream: requested alignment of %d recv_udp_stream: receive alignment and offset set... recv_udp_stream: grabbing a socket... recv_udp_stream: about to enter inner sanctum. recv_udp_stream: connected data socket recv_udp_stream: got %d messages. recv_udp_stream: test ended in %f seconds. recv_udp_stream: got %d bytes recv_udp_stream: test complete, sending results. %-6d %-6d %-6d %-6d %-6.2f %-6.2f %-6.2f %-6.2f %-6.3f %-6.3f %s UDP REQUEST/RESPONSE TESTnetperf: send_udp_rr: udp rr data socketsend_udp_rr: send_socket obtained... netperf: send_udp_rr: requesting UDP r/r test send_udp_rr: initial burst data send errorsend_udp_rr: data send errorsend_udp_rr: data recv errornetserver: recv_udp_rr: entered... recv_udp_rr: setting the response type... recv_udp_rr: the response type is set... recv_udp_rr: requested recv alignment of %d offset %d recv_udp_rr: requested send alignment of %d offset %d recv_udp_rr: receive alignment and offset set... recv_udp_rr: grabbing a socket... recv port number %d recv_udp_rr: Transaction %d complete. recv_udp_rr: got %d transactions recv_udp_rr: test complete, sending results. netserver: recv_tcp_rr: entered... recv_tcp_rr: setting the response type... recv_tcp_rr: the response type is set... recv_tcp_rr: requested recv alignment of %d offset %d recv_tcp_rr: requested send alignment of %d offset %d recv_tcp_rr: grabbing a socket... recv_tcp_rr: accept completes on the data connection. zero is my hero yo5 yo6 recv_tcp_rr: got %d transactions recv_tcp_rr: test complete, sending results. %g There %s %d local %s areiscpuscpu There %s %d remote %s %-6d %-6d %-6d %-6d %-6.2f %7.2f Local /Remote Socket Size Request Resp. Elapsed Trans. CPU CPU S.dem S.dem Send Recv Size Size Time Rate local remote local remote bytes bytes bytes bytes secs. per sec %% %% us/Tr us/Tr %6.3f %-6d %-6d %-6d %-6d %-6.2f %-6.2f %-6.2f %-6.2f %-6.3f %-6.3f Alignment Offset Local Remote Local Remote Send Recv Send Recv %5d %5d %5d %5d TCP Connect/Request/Response TESTsend_tcp_conn_rr: send_socket obtained... netperf: send_tcp_conn_rr: requesting TCP crr test remote port is %u port %d netperf: send_tcp_conn_rr: tcp stream data socket attempted to connect on socket %d to port %d from port %d send_tcp_conn_rr: data send errorsend_tcp_conn_rr: data recv errorTransaction %d completed on local port %d WARNING WARNING WARNING WARNING WARNING WARNING WARNING! Local CPU usage numbers based on process information only! DANGER DANGER DANGER DANGER DANGER DANGER DANGER! Remote CPU usage numbers based on process information only! netserver: recv_tcp_conn_rr: entered... recv_tcp_conn_rr: setting the response type... recv_tcp_conn_rr: the response type is set... malloc(%d) failed! recv_tcp_conn_rr: requested recv alignment of %d offset %d recv_tcp_conn_rr: requested send alignment of %d offset %d recv_tcp_conn_rr: receive alignment and offset set... recv_tcp_conn_rr: grabbing a socket... could not create data socket could not listen could not getsockname telling the remote to call me at %d recv_tcp_conn_rr: accept: errno = %d recv_tcp_conn_rr: accepted data connection. recv_tcp_conn_rr: Transaction %d complete recv_tcp_conn_rr: got %d transactions recv_tcp_conn_rr: test complete, sending results. TCP Connect/Close TESTsend_tcp_cc: send_socket obtained... netperf: send_tcp_cc: requesting TCP crr test remote port is %d netperf: send_tcp_cc: tcp stream data socket from port %u Transaction %d completed on local port %u send_tcp_cc: data recv errornetserver: recv_tcp_cc: entered... recv_tcp_cc: setting the response type... recv_tcp_cc: the response type is set... recv_tcp_cc: requested recv alignment of %d offset %d recv_tcp_cc: requested send alignment of %d offset %d recv_tcp_cc: receive alignment and offset set... recv_tcp_cc: grabbing a socket... could not geetsockname recv_tcp_cc: accept: errno = %d recv_tcp_cc: accepted data connection. recv_tcp_cc: Transaction %d complete recv_tcp_cc: got %d transactions recv_tcp_cc: test complete, sending results. %s called with the following argument vector scan_sockets_args%s 0UDP_STREAMb:CDnNhH:L:m:M:p:P:r:R:s:S:T:Vw:W:z46WARNING: TCP_CORK not available on this platform! Local send copy avoidance not available. Local recv copy avoidance not available. STREAMSENDFILEdiscardRRechoMAERTSchargenNo default port known for the %s test, please set one yourself /dev/urandomrb%8.8x-%4.4x-%4.4x-%2.2x%2.2x-%2.2x %suuid string too small%s[%d]: idle %llu user %llu kernel %llu interrupt %llu cpu_util_init: kstat_open: errno %d %s cpusysMapping CPU instance %d to entry %d Sorry, this system has more CPUs (%d) than netperf can handle (%d). Please alter MAXCPUS in netlib.h and recompile. WARNING! WARNING! WARNING! WARNING! %s found an unexpected %s statistic %.16s %s is ignoring statistic %.16s cpu_nsec_idlecpu_nsec_usercpu_nsec_kernelcpu_nsec_intrFound a cpu_nsec_intr but it doesn't do what we want nsecget_cpu_countersget_cpu_counters could not find one or more of the expected counters! get_cpu_counters: kstat_read failed or chain id changed %d %s get_cpu_counters: kstat_lookup failed for module 'cpu' number %d instance %d name 'sys' and KSTAT_TYPE_NAMED: errno %d %s intrstattimeget_cpu_counters: kstat_lookup failed for module 'cpu' %d instance %d class 'intrstat' and KSTAT_TYPE_NAMED: errno %d %s delta_cpu_counterstotal_cpu_nsec %llu WARNING! WARNING! WARNING! WARNING! WARNING! calc_cpu_util_internal: more interrupt time than others combined! so CPU util cannot be estimated delta[%d].interrupt %llu delta[%d].idle %llu delta[%d].user %llu delta[%d].kernel %llu fraction_idle %llu interrupt_idle %llu fraction_user %llu interrupt_user %llu fraction_kernel %llu interrupt_kernel %llu corrected_cpu_counters fraction_idle %lu fraction_user %lu fraction_kernel %lu fraction_interrupt %lu lib_local_per_cpu_util[%d] %g cf %f socketmallocSIOCIFCONFEgressByAddrnoindexlo0callocUnknown AFwritereadLastHop AFNoAlphaUnavailableNot Implementedclass,.subsystem-vendor-idsubsystem-idvendor-iddevice-id/kstat_opencpu_infokstat_lookupkstat_readbrandclock_MHzCPU Not Found,sysinfoN/A,K LL*L:LJLZLjLzLLLLLLLLL MM*M:MJMZMjMzMMMMMMMMM NN*N:NJNZNjNzNNNNNNNNN OO*O:OJOZOjOzOOOOOOOOO PP*P:PJPZPjPzPPPPPPPPP QQ*Q:QJQZQjQzQQQQQQQQQ RR*R:RJRZRjRzRRRRRR;Teo  - y oo4GoptHDHo`oX*R@(#)netperf.c (c) Copyright 1993-2011 Hewlett-Packard Company. Version 2.5.0?$$$$@(#)netlib.c (c) Copyright 1993-2011 Hewlett-Packard Company. Version 2.5.0 Usage: netserver [options] Options: -h Display this text -D Do not daemonize -d Increase debugging output -f Do not spawn chilren for each test, run serially -L name,family Use name to pick listen address and family for family -N No debugging output, even if netperf asks -p portnum Listen for connect requests on portnum. -4 Do IPv4 -6 Do IPv6 -v verbosity Specify the verbosity level -V Display version information and exit Usage: netperf [global options] -- [test options] Global options: -a send,recv Set the local send,recv buffer alignment -A send,recv Set the remote send,recv buffer alignment -B brandstr Specify a string to be emitted with brief output -c [cpu_rate] Report local CPU usage -C [cpu_rate] Report remote CPU usage -d Increase debugging output -D [secs,units] * Display interim results at least every secs seconds using units as the initial guess for units per second -f G|M|K|g|m|k Set the output units -F fill_file Pre-fill buffers with data from fill_file -h Display this text -H name|ip,fam * Specify the target machine and/or local ip and family -i max,min Specify the max and min number of iterations (15,1) -I lvl[,intvl] Specify confidence level (95 or 99) (99) and confidence interval in percentage (10) -j Keep additional timing statistics -l testlen Specify test duration (>0 secs) (<0 bytes|trans) -L name|ip,fam * Specify the local ip|name and address family -o send,recv Set the local send,recv buffer offsets -O send,recv Set the remote send,recv buffer offset -n numcpu Set the number of processors for CPU util -N Establish no control connection, do 'send' side only -p port,lport* Specify netserver port number and/or local port -P 0|1 Don't/Do display test headers -r Allow confidence to be hit on result only -s seconds Wait seconds between test setup and test start -S Set SO_KEEPALIVE on the data connection -t testname Specify test to perform -T lcpu,rcpu Request netperf/netserver be bound to local/remote cpu -v verbosity Specify the verbosity level -W send,recv Set the number of send,recv buffers -v level Set the verbosity level (default 1, min 0) -V Display the netperf version and exit For those options taking two parms, at least one must be specified; specifying one value without a comma will set both parms to that value, specifying a value with a leading comma will set just the second parm, a value with a trailing comma will set just the first. To set each parm to unique values, specify both and separate them with a comma. * For these options taking two parms, specifying one value with no comma will only set the first parms and will leave the second at the default value. To set the second value it must be preceded with a comma or be a comma-separated pair. This is to retain previous netperf behaviour. @(#)netsh.c (c) Copyright 1993-2011 Hewlett-Packard Company. Version 2.5.0.AExEE Usage: netperf [global options] -- [test options] TCP/UDP BSD Sockets Test Options: -b number Send number requests at start of _RR tests -C Set TCP_CORK when available -D [L][,R] Set TCP_NODELAY locally and/or remotely (TCP_*) -h Display this text -H name,fam Use name (or IP) and family as target of data connection -L name,fam Use name (or IP) and family as source of data connection -m bytes Set the send size (TCP_STREAM, UDP_STREAM) -M bytes Set the recv size (TCP_STREAM, UDP_STREAM) -n Use the connected socket for UDP locally -N Use the connected socket for UDP remotely -p min[,max] Set the min/max port numbers for TCP_CRR, TCP_TRR -P local[,remote] Set the local/remote port for the data socket -r req,[rsp] Set request/response sizes (TCP_RR, UDP_RR) -s send[,recv] Set local socket send/recv buffer sizes -S send[,recv] Set remote socket send/recv buffer sizes -4 Use AF_INET (eg IPv4) on both ends of the data conn -6 Use AF_INET6 (eg IPv6) on both ends of the data conn For those options taking two parms, at least one must be specified; specifying one value without a comma will set both parms to that value, specifying a value with a leading comma will set just the second parm, a value with a trailing comma will set just the first. To set each parm to unique values, specify both and separate them with a comma. @(#)nettest_bsd.c (c) Copyright 1993-2011 Hewlett-Packard Co. Version 2.5.0@(#)nettest_sctp.c (c) Copyright 2005-2007 Hewlett-Packard Co. Version 2.4.3@(#)nettest_sdp.c (c) Copyright 2007 Hewlett-Packard Co. Version 2.4.4@(#)netcpu_kstat10.c (c) Copyright 2005-2011, Hewlett-Packard Company Version 2.5.0-4GDHLHtH K R   @X*,-DDd 8-;<-NTD- _k-vD@vDkd-@V( V W DlEvDk-D U vDk/( `t   .y BpEW<e<s<tEuE==vpEk<ExEvDk-@vDk-@vDk-@vDkC@vDkC@"vDk-@1< LP \ h yp  vEkDPp $DQ P P& L .e B XE k vEk$D|DvDk-@vDk-@  DDD D vkD@%6P DJ` d vDkD@DvvDk-@,$QDM TOdOD@ xC@z "O+;LE<<W r=.u p NP<TQ`L Q <*t9FX-!`q} <`b (DT#  4Q4MTN  H.>QD.] 7  s4- .@. p M%a 0<A0.cx qTM / M z DL`! px  tP 6  T tO\ |Ch  O .L d-MW- / = ` p  P.% 02 5 OF .U c -w  d  P @e 4O L<TR  Ъ N ^   tC [  \R'  > # P QU hCb Ln /b~ dQ   P r X 0d TL  H $L     . xE P b -n t D   P s CG   = | @N + DR> <8 <H [q Z Ma M l Kv $P~ L @3 N д ` CM DP #  M!(J *@<< L4-Taz aoK 8.4N0 ) m $OP, -,= 6p.NQ\@WV hvr -DN \ <`XY /x `c  DQ2 'P-: <CLGPL S [dNbQk1 sP TPtQX*p` -m $RB 0! ONp P %<6|FP !M [v> v-Y X.NOC$ <$.<;E@YY OUO_eg <i }  L$N(.LdRN4L B 4PD<, W AXA RI fR"~WY 0 dLD \Lo' (  0Y X<K 0~ 0<9` IpY RaDhT<utN~L -P <.QR <M 0 $MnS &P$- >0 IP `m p/tM <M c7  @~1>R9y0|  pC$ 0pS{ 6| P! [@gmRzhwn T<а Qc*  Lf O MO0~ !p6 h к 7@DODX*K .dHx.`^f _ ` QЧV <.O !10E 9`OMVtR^DMdRp`.8EP  %  00 l-n  .>v* KlCXO\/l9 o<O0 N4RdMXy 4Q 0w   & 58B/R Y  g-vH<   L-@-MLs*  .R,$ 7N>@ N8<].udPx. m h.P<pN.N$ Y Pje 5@f FPRb-Mi 2 PZ tL[-  X pv L  Q0p $-8P`J >Pn' KPS netperfcrti.scrt1.ocrt1.s__get_exit_frame_monitor_ptr__do_exit_code_ptrfsr.strap_tablevalues-Xa.cDdata.dataBbss.bssDrodata.rodatanetperf.cnetlib.c_xmknod_unameusec_per_itvlmeasuring_cpunetsh.cconvert_to_uppernettest_bsd.cget_tcp_infoget_port_numberextract_inet_address_and_portget_address_addressconfidence_iterationintvl_one_ptrintvl_two_ptrtemp_intvl_ptrlocal_cpu_methodremote_cpu_methodclient_port_maxclient_port_minintvl_oneintvl_twonettest_dlpi.cnettest_unix.cnettest_xti.cnettest_sctp.cnettest_sdp.cnettest_omni.cnet_uuid.cget_system_timeget_random_infotrue_randomget_current_timeget_ieee_node_identifierformat_uuid_v1netcpu_kstat10.cprint_cpu_time_counterskcprint_unexpected_statistic_warningget_cpu_countersget_interrupt_countersget_cpu_time_countersending_cpu_countersstarting_cpu_countersdelta_cpu_counterscorrected_cpu_counterskcidnetrt_rtmget.cnetdrv_solaris.cnetslot_solaris.cset_interface_matchparse_binding_namefound_vendorfound_devicefound_subvendorfound_subdevicecheck_nodenetsys_solaris.cfind_cpu_model_freqfind_system_model_sysinfofind_system_modelnetsec_none.ccrtn.s_END__START_debug_DYNAMICfwriterem_dirty_countnst_to_hstcreate_data_socketprocessor_bindrecv_udp_streamloc_tcpcorkoptindrecv_request_ngai_strerrornetperf_requestsetitimerlocal_send_offsetcalculate_confidenceprint_sockets_usagemeasured_var_local_cpushutdown_controloutput_rowmemsetlistenwant_keepalivekstat_lookupHIST_get_percentileif_indextonamerecv_responsetest_len_tickslss_size_reqinterval_countloc_sndavoidnetperf_response_environlib_num_loc_cpusrecv_response_timed_nrsr_size_reqprint_top_test_headernetcpu_kstat10_idbreak_args_explicit_seprecv_tcp_streamkstat_opensigaddsetstat64local_data_portlib_elapsedmeasured_var_local_service_demandioctlmeasured_mean_local_timesend_udp_streamparse_socket_typemeasured_square_sum_resulttzset_defaultsmeasured_mean_local_cpumeasured_mean_local_service_demand__iobresponse_arraybreak_args_explicitsend_tcp_streamstrstrstop_timerfirst_burst_sizemeasured_sum_local_service_demandscan_cmd_lineremote_versionstrdupdi_initremote_data_familyremote_interval_usecsestablish_control__assertsend_responsefflushwait_time_secsget_rem_cpu_confidsend_requestsprintflib_remote_peak_cpu_idfind_egress_interface_by_linkconnectrem_tcpcorkfind_egress_interface_by_addrstrchrnetlib_idnetperf_idlocal_data_familycalc_service_demand_internaldisplay_confidenceformat_numberkeep_statisticsmeasured_sum_remote_service_demandget_uuid_stringgettimeofdayget_loc_cpu_confidlocal_sysnamemeasured_var_resultlocal_releaselsr_size_endlocal_machinelib_remote_maxrateconvertmsec_sleepresult_confidence_onlydump_globalsget_cpu_methodsendcatcherresolve_hosthtonditeration_mincalc_cpu_util_internalfind_system_infofreadrss_size_endhtonlprint_netserver_usagekstat_readusernamerequest_arrayhtonscalibrate_local_cpulocal_address_familynetlib_initstrcasecmpprint_headerslib_num_rem_cpus_exitbreak_argsHIST_newmeasured_square_sum_remote_cpuremote_send_widthlib_local_maxrateserver_sockerrnolib_local_cpu_utilcommand_linecpu_stopgetsocknamecalibrate_remote_cpunettest_sdpcpu_start_internalmeasured_local_resultsrecv_tcp_ccrecv_requestset_sockaddr_family_addr_portdi_prop_intsrouting_allowedrandom_ip_addressstrcmpHIST_clear__fpstarttoupperlib_use_idlescan_sockets_argsrecvparse_address_familydemo_intervalnettest_sctpatofsend_tcp_rrestablish_control_internalatoilocal_recv_aligncalc_thruput_intervallocal_recv_offsetlocal_test_port___Argvstart_itimeriteration_max_PROCEDURE_LINKAGE_TABLE_measured_square_sum_local_service_demandrecv_response_ncomplete_addrinfogetaddrinfoHIST_purgeconfidence_leveltest_transcontrol_familyremote_interval_burstcpu_startmeasured_sum_local_timedi_minor_namestop_itimerinterval_wateformat_cpu_methodmeasured_mean_resultfopen64recv_udp_rrnf_to_afinet_ttosno_controlsend_response_nget_local_system_infofind_interface_slotkstat_closecalc_thruput_omnibzeroidentify_localnettest_idsend_udp_rrunknownstrcpyrecvfromlibmainloc_dirty_countset_sock_bufferstrtodprogram__udiv64_GLOBAL_OFFSET_TABLE_start_timerlibfmtrem_cpu_ratedi_prop_namesetsockoptstrtokdump_addrinfostrtolrecv_tcp_maertsremote_connectedremote_sysname__ctypecalc_cpu_utilbind_to_specific_processor__environ_lockhst_to_strlib_remote_peak_cpu_utilmeasured_square_sum_remote_service_demandselect__fsr_init_valuegetsockoptmulticast_ttlHIST_get_statsremote_cpu_usagerecv_sizelsr_size_reqtest_nameinet_ftostime1gethrtimetime2calc_service_demand_fmtHIST_addrem_clean_countunlinkmeasured_var_remote_cpulib_local_peak_cpu_utilsranddi_walk_nodemkstemp64fprintfHIST_search_bucketrem_sndavoidgetoptremote_send_offsetnetlib_get_page_sizensec_type_to_strcalc_service_demand_get_exit_frame_monitornsec_enabled_to_strHIST_timestamp_startset_hostname_and_portlocal_versionlsr_sizeremote_recv_alignatexitdump_responseremote_data_porthst_to_nstnetsh_ididentify_remotersp_sizesend_tcp_maertsaf_to_nfmeasured_fails_edataresult_brandshutdownsnprintfcpu_stop_internalremote_proc_affinityremote_recv_widthget_result_confidsendtodi_binding_namefind_interface_idsrss_size_reqfind_security_infosigactionacceptfind_driver_infoHIST_new_nget_remote_system_infoprotocol_to_strremote_data_addressset_port_numberreq_sizenetlib_init_cpu_maprecv_response_timed_lib_versionlss_sizenetperf_usage1di_prop_nextnetperf_usage2recv_tcp_conn_rrlss_size_endHIST_report__fsrretrieve_confident_valuestest_bytesloc_nodelaywheresmbios_closeverbosityunits_this_ticksend_request_nremote_machinedemo_unitscalibrate_idle_ratefreerecv_tcp_rrsysconfallocate_buffer_ring__xtolcalc_thruput_interval_omnifind_egress_interfaceloc_rcvavoid_etextmeasured_mean_remote_cpulib_remote_cpu_utilmeasured_sum_remote_cpuget_num_cpusinstall_signal_catchersget_idmemcmpuuid_createtest_timerem_nodelaymeasured_mean_remote_timefreeaddrinfolib_cpu_mapcmd_filenetperf_versionsum_rowlib_local_peak_cpu_idmallocdi_finialarmsmbios_openmeasured_mean_remote_service_demandremote_releasersr_sizecpu_util_terminateprint_netperf_usagesnpuidinit_statconfidence_iterationsmeasured_sum_resultlocal_cpu_ratesend_tcp_conn_rrloc_clean_countset_nonblockrsr_size_endpowlocal_data_addresslocal_connectedsqrtdelta_microlocal_send_aligntimes_updi_prop_typegetpidinet_ptoslocal_cpu_usagecallocsendfile_tcp_streamsend_tcp_cc__1cG__CrunMdo_exit_code6F_v_HIST_timestamp_stop_addrem_rcvavoidlib_local_per_cpu_utilcpu_util_initnetlib_controlremote_recv_offsetparse_protocolHIST_timestampmemcpymeasured_sum_local_cpu__longdouble_usedsigemptysetperrorformat_unitsoptargsmbios_info_commonrss_sizesend_sizecomplete_addrinfosstrlenget_sock_buffershell_num_cpusmeasured_var_local_timegetprotobynamemeasured_square_sum_local_timeloc_cpu_ratelocal_host_namemeasured_var_remote_service_demandcpu_binding_requestedfcntldemo_modeinet_ntoninet_ntopalloc_sendfile_buf_ringconvert_timespecsendfilev64remote_cpu_ratemeasured_square_sum_local_cpurewindaccess_buffercalc_thruputntohd_nunamerand32get_sockaddr_family_addr_portkeep_histogramntohldi_minor_nextfill_fileremote_send_alignparse_directionlocal_proc_affinityntohsdump_requeststrncpysend_tcp_mssanotate anotate0 ,(R,RyS8-<-anotate anotate WWWWWWXWXW_^`^sssrsrsrsss,ss ss8ssrsDssPssssrs\sanotate L4\ l $(T,048<@@DxHLMPLTX$\`Hdh<ltp|tx(|anotate !%)U@ML@DHLhPT <<ll$llDHHu375 77 171 71 737T47T4CCCCCBC`BC`BC0CDTCDTCY\[\\hW \ X \ X\Y\Z\Zz|{#||y|z|z#|z'|0{+|0{qmHcsǠs\wd{ˠˠ,\ˠĝpanotate anotate anotate anotate @(#)stdio.h 1.84 04/09/28 SMI@(#)feature_tests.h 1.25 07/02/02 SMI@(#)ccompile.h 1.2 04/11/08 SMI@(#)isa_defs.h 1.29 08/06/06 SMI@(#)stdio_iso.h 1.8 05/08/16 SMI@(#)va_list.h 1.15 04/11/19 SMI@(#)stdio_tag.h 1.4 04/09/28 SMI@(#)stdio_impl.h 1.15 07/03/05 SMI@(#)stdio_c99.h 1.2 04/03/29 SMI@(#)stdlib.h 1.51 04/06/30 SMI@(#)stdlib_iso.h 1.9 04/09/28 SMI@(#)stdlib_c99.h 1.2 04/03/29 SMI@(#)strings.h 1.3 96/03/12 SMI@(#)types.h 1.86 07/09/20 SMI@(#)machtypes.h 1.11 04/09/28 SMI@(#)machtypes.h 1.2 04/09/28 SMI@(#)int_types.h 1.10 04/09/28 SMI@(#)select.h 1.19 04/01/28 SMI@(#)time_impl.h 1.11 05/05/19 SMI@(#)time.h 2.77 09/06/02 SMI@(#)time.h 1.45 08/01/09 SMI@(#)time_iso.h 1.4 04/09/07 SMI@(#)string.h 1.27 07/01/14 SMI@(#)string_iso.h 1.5 04/06/18 SMI@(#)socket.h 1.78 08/01/18 SMI@(#)uio.h 1.34 09/06/15 SMI@(#)socket_impl.h 1.1 05/08/02 SMI@(#)un.h 1.11 02/10/02 SMI@(#)if_dl.h 1.10 03/05/21 SMI@(#)netconfig.h 1.24 04/02/27 SMI@(#)in.h 1.55 09/05/27 SMI@(#)stream.h 1.115 08/07/22 SMI@(#)vnode.h 1.133 09/07/17 SMI@(#)t_lock.h 1.45 98/02/01 SMI@(#)machlock.h 1.25 04/07/19 SMI@(#)param.h 1.82 06/01/30 SMI@(#)unistd.h 1.43 06/03/10 SMI@(#)mutex.h 1.21 07/04/04 SMI@(#)rwlock.h 1.9 98/02/18 SMI@(#)semaphore.h 1.5 98/02/01 SMI@(#)condvar.h 1.14 04/10/21 SMI@(#)rwstlock.h 1.4 04/11/09 SMI@(#)ksynch.h 1.6 97/10/22 SMI@(#)cred.h 1.27 06/05/03 SMI@(#)resource.h 1.37 07/02/07 SMI@(#)seg_enum.h 1.9 09/07/02 SMI@(#)kstat.h 1.22 07/02/02 SMI@(#)kmem.h 1.38 09/05/07 SMI@(#)vmem.h 1.12 05/06/27 SMI@(#)poll.h 1.28 98/11/23 SMI@(#)strmdep.h 1.10 98/01/06 SMI@(#)model.h 1.24 04/09/28 SMI@(#)strft.h 1.2 00/03/17 SMI@(#)byteorder.h 1.18 04/09/28 SMI@(#)netdb.h 1.30 03/12/04 SMI@(#)inttypes.h 1.4 04/04/29 SMI@(#)inttypes.h 1.3 03/12/04 SMI@(#)int_limits.h 1.9 04/09/28 SMI@(#)int_const.h 1.5 04/09/28 SMI@(#)int_fmtio.h 1.6 04/09/28 SMI@(#)stdint.h 1.1 03/12/04 SMIacomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13@(#)limits.h 1.59 04/08/24 SMI@(#)feature_tests.h 1.25 07/02/02 SMI@(#)ccompile.h 1.2 04/11/08 SMI@(#)isa_defs.h 1.29 08/06/06 SMI@(#)limits_iso.h 1.2 03/12/04 SMI@(#)int_limits.h 1.9 04/09/28 SMI@(#)signal.h 1.43 04/09/28 SMI@(#)types.h 1.86 07/09/20 SMI@(#)machtypes.h 1.11 04/09/28 SMI@(#)machtypes.h 1.2 04/09/28 SMI@(#)int_types.h 1.10 04/09/28 SMI@(#)select.h 1.19 04/01/28 SMI@(#)time_impl.h 1.11 05/05/19 SMI@(#)time.h 2.77 09/06/02 SMI@(#)time.h 1.45 08/01/09 SMI@(#)time_iso.h 1.4 04/09/07 SMI@(#)signal_iso.h 1.1 99/08/09 SMI@(#)signal_iso.h 1.6 03/05/02 SMI@(#)unistd.h 1.43 06/03/10 SMI@(#)signal.h 1.66 04/09/28 SMI@(#)siginfo.h 1.59 04/07/15 SMI@(#)machsig.h 1.11 03/09/26 SMI@(#)faultcode.h 1.16 09/07/02 SMI@(#)procset.h 1.25 04/07/16 SMI@(#)fcntl.h 1.17 06/03/10 SMI@(#)fcntl.h 1.52 07/03/05 SMI@(#)stdio.h 1.84 04/09/28 SMI@(#)stdio_iso.h 1.8 05/08/16 SMI@(#)va_list.h 1.15 04/11/19 SMI@(#)stdio_tag.h 1.4 04/09/28 SMI@(#)stdio_impl.h 1.15 07/03/05 SMI@(#)stdio_c99.h 1.2 04/03/29 SMI@(#)stdlib.h 1.51 04/06/30 SMI@(#)stdlib_iso.h 1.9 04/09/28 SMI@(#)stdlib_c99.h 1.2 04/03/29 SMI@(#)math.h 2.24 04/10/23 SMI@(#)math_iso.h 1.9 04/10/23 SMI@(#)math_c99.h 1.9 04/11/01 SMI@(#)floatingpoint.h 2.9 04/10/23 SMI@(#)ieeefp.h 2.12 04/10/23 SMI@(#)string.h 1.27 07/01/14 SMI@(#)string_iso.h 1.5 04/06/18 SMI@(#)assert.h 1.10 04/05/18 SMI@(#)unistd.h 1.76 06/03/10 SMI@(#)stat.h 1.11 04/09/28 SMI@(#)stat_impl.h 1.4 03/12/04 SMI@(#)times.h 1.10 97/08/12 SMI@(#)socket.h 1.78 08/01/18 SMI@(#)uio.h 1.34 09/06/15 SMI@(#)socket_impl.h 1.1 05/08/02 SMI@(#)un.h 1.11 02/10/02 SMI@(#)if_dl.h 1.10 03/05/21 SMI@(#)netconfig.h 1.24 04/02/27 SMI@(#)in.h 1.55 09/05/27 SMI@(#)stream.h 1.115 08/07/22 SMI@(#)vnode.h 1.133 09/07/17 SMI@(#)t_lock.h 1.45 98/02/01 SMI@(#)machlock.h 1.25 04/07/19 SMI@(#)param.h 1.82 06/01/30 SMI@(#)mutex.h 1.21 07/04/04 SMI@(#)rwlock.h 1.9 98/02/18 SMI@(#)semaphore.h 1.5 98/02/01 SMI@(#)condvar.h 1.14 04/10/21 SMI@(#)rwstlock.h 1.4 04/11/09 SMI@(#)ksynch.h 1.6 97/10/22 SMI@(#)cred.h 1.27 06/05/03 SMI@(#)resource.h 1.37 07/02/07 SMI@(#)seg_enum.h 1.9 09/07/02 SMI@(#)kstat.h 1.22 07/02/02 SMI@(#)kmem.h 1.38 09/05/07 SMI@(#)vmem.h 1.12 05/06/27 SMI@(#)poll.h 1.28 98/11/23 SMI@(#)strmdep.h 1.10 98/01/06 SMI@(#)model.h 1.24 04/09/28 SMI@(#)strft.h 1.2 00/03/17 SMI@(#)byteorder.h 1.18 04/09/28 SMI@(#)inet.h 1.21 08/01/04 SMI@(#)netdb.h 1.30 03/12/04 SMI@(#)errno.h 1.17 03/01/03 SMI@(#)errno.h 1.20 00/01/12 SMI@(#)utsname.h 1.30 04/09/28 SMI@(#)inttypes.h 1.4 04/04/29 SMI@(#)inttypes.h 1.3 03/12/04 SMI@(#)int_const.h 1.5 04/09/28 SMI@(#)int_fmtio.h 1.6 04/09/28 SMI@(#)stdint.h 1.1 03/12/04 SMI@(#)processor.h 1.13 08/11/14 SMIacomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13@(#)types.h 1.86 07/09/20 SMI@(#)feature_tests.h 1.25 07/02/02 SMI@(#)ccompile.h 1.2 04/11/08 SMI@(#)isa_defs.h 1.29 08/06/06 SMI@(#)machtypes.h 1.11 04/09/28 SMI@(#)machtypes.h 1.2 04/09/28 SMI@(#)int_types.h 1.10 04/09/28 SMI@(#)select.h 1.19 04/01/28 SMI@(#)time_impl.h 1.11 05/05/19 SMI@(#)time.h 2.77 09/06/02 SMI@(#)time.h 1.45 08/01/09 SMI@(#)time_iso.h 1.4 04/09/07 SMI@(#)unistd.h 1.76 06/03/10 SMI@(#)unistd.h 1.43 06/03/10 SMI@(#)ipc.h 1.23 03/02/05 SMI@(#)fcntl.h 1.17 06/03/10 SMI@(#)fcntl.h 1.52 07/03/05 SMI@(#)errno.h 1.17 03/01/03 SMI@(#)errno.h 1.20 00/01/12 SMI@(#)signal.h 1.43 04/09/28 SMI@(#)signal_iso.h 1.1 99/08/09 SMI@(#)signal_iso.h 1.6 03/05/02 SMI@(#)signal.h 1.66 04/09/28 SMI@(#)siginfo.h 1.59 04/07/15 SMI@(#)machsig.h 1.11 03/09/26 SMI@(#)faultcode.h 1.16 09/07/02 SMI@(#)procset.h 1.25 04/07/16 SMI@(#)stdio.h 1.84 04/09/28 SMI@(#)stdio_iso.h 1.8 05/08/16 SMI@(#)va_list.h 1.15 04/11/19 SMI@(#)stdio_tag.h 1.4 04/09/28 SMI@(#)stdio_impl.h 1.15 07/03/05 SMI@(#)stdio_c99.h 1.2 04/03/29 SMI@(#)stdlib.h 1.51 04/06/30 SMI@(#)stdlib_iso.h 1.9 04/09/28 SMI@(#)stdlib_c99.h 1.2 04/03/29 SMI@(#)ctype.h 1.35 04/09/28 SMI@(#)ctype_iso.h 1.3 04/09/28 SMI@(#)ctype_c99.h 1.2 04/09/28 SMI@(#)socket.h 1.78 08/01/18 SMI@(#)uio.h 1.34 09/06/15 SMI@(#)socket_impl.h 1.1 05/08/02 SMI@(#)un.h 1.11 02/10/02 SMI@(#)if_dl.h 1.10 03/05/21 SMI@(#)netconfig.h 1.24 04/02/27 SMI@(#)in.h 1.55 09/05/27 SMI@(#)stream.h 1.115 08/07/22 SMI@(#)vnode.h 1.133 09/07/17 SMI@(#)t_lock.h 1.45 98/02/01 SMI@(#)machlock.h 1.25 04/07/19 SMI@(#)param.h 1.82 06/01/30 SMI@(#)mutex.h 1.21 07/04/04 SMI@(#)rwlock.h 1.9 98/02/18 SMI@(#)semaphore.h 1.5 98/02/01 SMI@(#)condvar.h 1.14 04/10/21 SMI@(#)rwstlock.h 1.4 04/11/09 SMI@(#)ksynch.h 1.6 97/10/22 SMI@(#)cred.h 1.27 06/05/03 SMI@(#)resource.h 1.37 07/02/07 SMI@(#)seg_enum.h 1.9 09/07/02 SMI@(#)kstat.h 1.22 07/02/02 SMI@(#)kmem.h 1.38 09/05/07 SMI@(#)vmem.h 1.12 05/06/27 SMI@(#)poll.h 1.28 98/11/23 SMI@(#)strmdep.h 1.10 98/01/06 SMI@(#)model.h 1.24 04/09/28 SMI@(#)strft.h 1.2 00/03/17 SMI@(#)byteorder.h 1.18 04/09/28 SMI@(#)inet.h 1.21 08/01/04 SMI@(#)netdb.h 1.30 03/12/04 SMI@(#)string.h 1.27 07/01/14 SMI@(#)string_iso.h 1.5 04/06/18 SMI@(#)inttypes.h 1.4 04/04/29 SMI@(#)inttypes.h 1.3 03/12/04 SMI@(#)int_limits.h 1.9 04/09/28 SMI@(#)int_const.h 1.5 04/09/28 SMI@(#)int_fmtio.h 1.6 04/09/28 SMI@(#)stdint.h 1.1 03/12/04 SMIacomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13@(#)stdio.h 1.84 04/09/28 SMI@(#)feature_tests.h 1.25 07/02/02 SMI@(#)ccompile.h 1.2 04/11/08 SMI@(#)isa_defs.h 1.29 08/06/06 SMI@(#)stdio_iso.h 1.8 05/08/16 SMI@(#)va_list.h 1.15 04/11/19 SMI@(#)stdio_tag.h 1.4 04/09/28 SMI@(#)stdio_impl.h 1.15 07/03/05 SMI@(#)stdio_c99.h 1.2 04/03/29 SMI@(#)types.h 1.86 07/09/20 SMI@(#)machtypes.h 1.11 04/09/28 SMI@(#)machtypes.h 1.2 04/09/28 SMI@(#)int_types.h 1.10 04/09/28 SMI@(#)select.h 1.19 04/01/28 SMI@(#)time_impl.h 1.11 05/05/19 SMI@(#)time.h 2.77 09/06/02 SMI@(#)time.h 1.45 08/01/09 SMI@(#)time_iso.h 1.4 04/09/07 SMI@(#)stat.h 1.11 04/09/28 SMI@(#)stat_impl.h 1.4 03/12/04 SMI@(#)stdlib.h 1.51 04/06/30 SMI@(#)stdlib_iso.h 1.9 04/09/28 SMI@(#)stdlib_c99.h 1.2 04/03/29 SMI@(#)stddef.h 1.18 04/09/28 SMI@(#)stddef_iso.h 1.2 03/03/06 SMI@(#)string.h 1.27 07/01/14 SMI@(#)string_iso.h 1.5 04/06/18 SMI@(#)strings.h 1.3 96/03/12 SMI@(#)inttypes.h 1.4 04/04/29 SMI@(#)inttypes.h 1.3 03/12/04 SMI@(#)int_limits.h 1.9 04/09/28 SMI@(#)int_const.h 1.5 04/09/28 SMI@(#)int_fmtio.h 1.6 04/09/28 SMI@(#)stdint.h 1.1 03/12/04 SMI@(#)unistd.h 1.76 06/03/10 SMI@(#)unistd.h 1.43 06/03/10 SMI@(#)fcntl.h 1.17 06/03/10 SMI@(#)fcntl.h 1.52 07/03/05 SMI@(#)errno.h 1.17 03/01/03 SMI@(#)errno.h 1.20 00/01/12 SMI@(#)signal.h 1.43 04/09/28 SMI@(#)signal_iso.h 1.1 99/08/09 SMI@(#)signal_iso.h 1.6 03/05/02 SMI@(#)signal.h 1.66 04/09/28 SMI@(#)siginfo.h 1.59 04/07/15 SMI@(#)machsig.h 1.11 03/09/26 SMI@(#)faultcode.h 1.16 09/07/02 SMI@(#)procset.h 1.25 04/07/16 SMI@(#)ipc.h 1.23 03/02/05 SMI@(#)socket.h 1.78 08/01/18 SMI@(#)uio.h 1.34 09/06/15 SMI@(#)socket_impl.h 1.1 05/08/02 SMI@(#)un.h 1.11 02/10/02 SMI@(#)if_dl.h 1.10 03/05/21 SMI@(#)netconfig.h 1.24 04/02/27 SMI@(#)in.h 1.55 09/05/27 SMI@(#)stream.h 1.115 08/07/22 SMI@(#)vnode.h 1.133 09/07/17 SMI@(#)t_lock.h 1.45 98/02/01 SMI@(#)machlock.h 1.25 04/07/19 SMI@(#)param.h 1.82 06/01/30 SMI@(#)mutex.h 1.21 07/04/04 SMI@(#)rwlock.h 1.9 98/02/18 SMI@(#)semaphore.h 1.5 98/02/01 SMI@(#)condvar.h 1.14 04/10/21 SMI@(#)rwstlock.h 1.4 04/11/09 SMI@(#)ksynch.h 1.6 97/10/22 SMI@(#)cred.h 1.27 06/05/03 SMI@(#)resource.h 1.37 07/02/07 SMI@(#)seg_enum.h 1.9 09/07/02 SMI@(#)kstat.h 1.22 07/02/02 SMI@(#)kmem.h 1.38 09/05/07 SMI@(#)vmem.h 1.12 05/06/27 SMI@(#)poll.h 1.28 98/11/23 SMI@(#)strmdep.h 1.10 98/01/06 SMI@(#)model.h 1.24 04/09/28 SMI@(#)strft.h 1.2 00/03/17 SMI@(#)byteorder.h 1.18 04/09/28 SMI@(#)tcp.h 1.18 05/12/21 SMI@(#)inet.h 1.21 08/01/04 SMI@(#)netdb.h 1.30 03/12/04 SMI@(#)sendfile.h 1.4 04/09/28 SMIacomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13acomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13acomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13acomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13acomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13acomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13acomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13@(#)stdio.h 1.84 04/09/28 SMI@(#)feature_tests.h 1.25 07/02/02 SMI@(#)ccompile.h 1.2 04/11/08 SMI@(#)isa_defs.h 1.29 08/06/06 SMI@(#)stdio_iso.h 1.8 05/08/16 SMI@(#)va_list.h 1.15 04/11/19 SMI@(#)stdio_tag.h 1.4 04/09/28 SMI@(#)stdio_impl.h 1.15 07/03/05 SMI@(#)stdio_c99.h 1.2 04/03/29 SMI@(#)stdlib.h 1.51 04/06/30 SMI@(#)stdlib_iso.h 1.9 04/09/28 SMI@(#)stdlib_c99.h 1.2 04/03/29 SMI@(#)string.h 1.27 07/01/14 SMI@(#)string_iso.h 1.5 04/06/18 SMI@(#)inttypes.h 1.4 04/04/29 SMI@(#)inttypes.h 1.3 03/12/04 SMI@(#)int_types.h 1.10 04/09/28 SMI@(#)int_limits.h 1.9 04/09/28 SMI@(#)int_const.h 1.5 04/09/28 SMI@(#)int_fmtio.h 1.6 04/09/28 SMI@(#)stdint.h 1.1 03/12/04 SMI@(#)types.h 1.86 07/09/20 SMI@(#)machtypes.h 1.11 04/09/28 SMI@(#)machtypes.h 1.2 04/09/28 SMI@(#)select.h 1.19 04/01/28 SMI@(#)time_impl.h 1.11 05/05/19 SMI@(#)time.h 2.77 09/06/02 SMI@(#)time.h 1.45 08/01/09 SMI@(#)time_iso.h 1.4 04/09/07 SMI@(#)sysinfo.h 1.31 10/04/13 SMI@(#)t_lock.h 1.45 98/02/01 SMI@(#)machlock.h 1.25 04/07/19 SMI@(#)param.h 1.82 06/01/30 SMI@(#)unistd.h 1.43 06/03/10 SMI@(#)mutex.h 1.21 07/04/04 SMI@(#)rwlock.h 1.9 98/02/18 SMI@(#)semaphore.h 1.5 98/02/01 SMI@(#)condvar.h 1.14 04/10/21 SMI@(#)kstat.h 1.22 07/02/02 SMIacomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13@(#)stdio.h 1.84 04/09/28 SMI@(#)feature_tests.h 1.25 07/02/02 SMI@(#)ccompile.h 1.2 04/11/08 SMI@(#)isa_defs.h 1.29 08/06/06 SMI@(#)stdio_iso.h 1.8 05/08/16 SMI@(#)va_list.h 1.15 04/11/19 SMI@(#)stdio_tag.h 1.4 04/09/28 SMI@(#)stdio_impl.h 1.15 07/03/05 SMI@(#)stdio_c99.h 1.2 04/03/29 SMI@(#)inttypes.h 1.4 04/04/29 SMI@(#)inttypes.h 1.3 03/12/04 SMI@(#)int_types.h 1.10 04/09/28 SMI@(#)int_limits.h 1.9 04/09/28 SMI@(#)int_const.h 1.5 04/09/28 SMI@(#)int_fmtio.h 1.6 04/09/28 SMI@(#)stdint.h 1.1 03/12/04 SMI@(#)unistd.h 1.76 06/03/10 SMI@(#)types.h 1.86 07/09/20 SMI@(#)machtypes.h 1.11 04/09/28 SMI@(#)machtypes.h 1.2 04/09/28 SMI@(#)select.h 1.19 04/01/28 SMI@(#)time_impl.h 1.11 05/05/19 SMI@(#)time.h 2.77 09/06/02 SMI@(#)time.h 1.45 08/01/09 SMI@(#)time_iso.h 1.4 04/09/07 SMI@(#)unistd.h 1.43 06/03/10 SMI@(#)strings.h 1.3 96/03/12 SMI@(#)string.h 1.27 07/01/14 SMI@(#)string_iso.h 1.5 04/06/18 SMI@(#)stdlib.h 1.51 04/06/30 SMI@(#)stdlib_iso.h 1.9 04/09/28 SMI@(#)stdlib_c99.h 1.2 04/03/29 SMI@(#)stddef.h 1.18 04/09/28 SMI@(#)stddef_iso.h 1.2 03/03/06 SMI@(#)errno.h 1.17 03/01/03 SMI@(#)errno.h 1.20 00/01/12 SMI@(#)kstat.h 1.4 93/06/30 SMI@(#)kstat.h 1.22 07/02/02 SMI@(#)sysinfo.h 1.31 10/04/13 SMI@(#)t_lock.h 1.45 98/02/01 SMI@(#)machlock.h 1.25 04/07/19 SMI@(#)param.h 1.82 06/01/30 SMI@(#)mutex.h 1.21 07/04/04 SMI@(#)rwlock.h 1.9 98/02/18 SMI@(#)semaphore.h 1.5 98/02/01 SMI@(#)condvar.h 1.14 04/10/21 SMI@(#)socket.h 1.78 08/01/18 SMI@(#)uio.h 1.34 09/06/15 SMI@(#)socket_impl.h 1.1 05/08/02 SMI@(#)un.h 1.11 02/10/02 SMI@(#)if_dl.h 1.10 03/05/21 SMI@(#)netconfig.h 1.24 04/02/27 SMI@(#)in.h 1.55 09/05/27 SMI@(#)stream.h 1.115 08/07/22 SMI@(#)vnode.h 1.133 09/07/17 SMI@(#)rwstlock.h 1.4 04/11/09 SMI@(#)ksynch.h 1.6 97/10/22 SMI@(#)cred.h 1.27 06/05/03 SMI@(#)resource.h 1.37 07/02/07 SMI@(#)seg_enum.h 1.9 09/07/02 SMI@(#)kmem.h 1.38 09/05/07 SMI@(#)vmem.h 1.12 05/06/27 SMI@(#)poll.h 1.28 98/11/23 SMI@(#)strmdep.h 1.10 98/01/06 SMI@(#)model.h 1.24 04/09/28 SMI@(#)strft.h 1.2 00/03/17 SMI@(#)byteorder.h 1.18 04/09/28 SMI@(#)netdb.h 1.30 03/12/04 SMIacomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13@(#)stdio.h 1.84 04/09/28 SMI@(#)feature_tests.h 1.25 07/02/02 SMI@(#)ccompile.h 1.2 04/11/08 SMI@(#)isa_defs.h 1.29 08/06/06 SMI@(#)stdio_iso.h 1.8 05/08/16 SMI@(#)va_list.h 1.15 04/11/19 SMI@(#)stdio_tag.h 1.4 04/09/28 SMI@(#)stdio_impl.h 1.15 07/03/05 SMI@(#)stdio_c99.h 1.2 04/03/29 SMI@(#)string.h 1.27 07/01/14 SMI@(#)string_iso.h 1.5 04/06/18 SMI@(#)types.h 1.86 07/09/20 SMI@(#)machtypes.h 1.11 04/09/28 SMI@(#)machtypes.h 1.2 04/09/28 SMI@(#)int_types.h 1.10 04/09/28 SMI@(#)select.h 1.19 04/01/28 SMI@(#)time_impl.h 1.11 05/05/19 SMI@(#)time.h 2.77 09/06/02 SMI@(#)time.h 1.45 08/01/09 SMI@(#)time_iso.h 1.4 04/09/07 SMI@(#)socket.h 1.78 08/01/18 SMI@(#)uio.h 1.34 09/06/15 SMI@(#)socket_impl.h 1.1 05/08/02 SMI@(#)un.h 1.11 02/10/02 SMI@(#)if_dl.h 1.10 03/05/21 SMI@(#)netconfig.h 1.24 04/02/27 SMI@(#)in.h 1.55 09/05/27 SMI@(#)stream.h 1.115 08/07/22 SMI@(#)vnode.h 1.133 09/07/17 SMI@(#)t_lock.h 1.45 98/02/01 SMI@(#)machlock.h 1.25 04/07/19 SMI@(#)param.h 1.82 06/01/30 SMI@(#)unistd.h 1.43 06/03/10 SMI@(#)mutex.h 1.21 07/04/04 SMI@(#)rwlock.h 1.9 98/02/18 SMI@(#)semaphore.h 1.5 98/02/01 SMI@(#)condvar.h 1.14 04/10/21 SMI@(#)rwstlock.h 1.4 04/11/09 SMI@(#)ksynch.h 1.6 97/10/22 SMI@(#)cred.h 1.27 06/05/03 SMI@(#)resource.h 1.37 07/02/07 SMI@(#)seg_enum.h 1.9 09/07/02 SMI@(#)kstat.h 1.22 07/02/02 SMI@(#)kmem.h 1.38 09/05/07 SMI@(#)vmem.h 1.12 05/06/27 SMI@(#)poll.h 1.28 98/11/23 SMI@(#)strmdep.h 1.10 98/01/06 SMI@(#)model.h 1.24 04/09/28 SMI@(#)strft.h 1.2 00/03/17 SMI@(#)byteorder.h 1.18 04/09/28 SMI@(#)socketvar.h 1.78 07/10/11 SMI@(#)file.h 1.70 07/03/05 SMI@(#)zone.h 1.21 10/01/08 SMI@(#)rctl.h 1.15 07/11/26 SMI@(#)ipc_rctl.h 1.1 07/02/07 SMI@(#)pset.h 1.6 08/11/14 SMI@(#)processor.h 1.13 08/11/14 SMI@(#)procset.h 1.25 04/07/16 SMI@(#)signal.h 1.66 04/09/28 SMI@(#)signal_iso.h 1.6 03/05/02 SMI@(#)siginfo.h 1.59 04/07/15 SMI@(#)machsig.h 1.11 03/09/26 SMI@(#)faultcode.h 1.16 09/07/02 SMI@(#)label.h 1.3 09/06/23 SMI@(#)netstack.h 1.3 09/01/06 SMI@(#)uadmin.h 1.31 07/01/14 SMI@(#)ksslapi.h 1.2 08/04/18 SMI@(#)inet.h 1.21 08/01/04 SMI@(#)if.h 1.38 07/03/20 SMI@(#)route.h 1.20 06/05/03 SMI@(#)label_macro.h 1.1 06/05/03 SMI@(#)unistd.h 1.76 06/03/10 SMI@(#)stdlib.h 1.51 04/06/30 SMI@(#)stdlib_iso.h 1.9 04/09/28 SMI@(#)stdlib_c99.h 1.2 04/03/29 SMI@(#)errno.h 1.17 03/01/03 SMI@(#)errno.h 1.20 00/01/12 SMI@(#)ioctl.h 1.9 92/07/14 SMI@(#)sockio.h 1.41 07/10/11 SMI@(#)ioccom.h 1.14 97/10/22 SMIacomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13@(#)string.h 1.27 07/01/14 SMI@(#)string_iso.h 1.5 04/06/18 SMI@(#)feature_tests.h 1.25 07/02/02 SMI@(#)ccompile.h 1.2 04/11/08 SMI@(#)isa_defs.h 1.29 08/06/06 SMI@(#)ctype.h 1.35 04/09/28 SMI@(#)ctype_iso.h 1.3 04/09/28 SMI@(#)ctype_c99.h 1.2 04/09/28 SMIacomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13@(#)string.h 1.27 07/01/14 SMI@(#)string_iso.h 1.5 04/06/18 SMI@(#)feature_tests.h 1.25 07/02/02 SMI@(#)ccompile.h 1.2 04/11/08 SMI@(#)isa_defs.h 1.29 08/06/06 SMI@(#)ctype.h 1.35 04/09/28 SMI@(#)ctype_iso.h 1.3 04/09/28 SMI@(#)ctype_c99.h 1.2 04/09/28 SMI@(#)stdlib.h 1.51 04/06/30 SMI@(#)stdlib_iso.h 1.9 04/09/28 SMI@(#)stdlib_c99.h 1.2 04/03/29 SMI@(#)if.h 1.38 07/03/20 SMI@(#)socket.h 1.78 08/01/18 SMI@(#)types.h 1.86 07/09/20 SMI@(#)machtypes.h 1.11 04/09/28 SMI@(#)machtypes.h 1.2 04/09/28 SMI@(#)int_types.h 1.10 04/09/28 SMI@(#)select.h 1.19 04/01/28 SMI@(#)time_impl.h 1.11 05/05/19 SMI@(#)time.h 2.77 09/06/02 SMI@(#)time.h 1.45 08/01/09 SMI@(#)time_iso.h 1.4 04/09/07 SMI@(#)uio.h 1.34 09/06/15 SMI@(#)socket_impl.h 1.1 05/08/02 SMI@(#)un.h 1.11 02/10/02 SMI@(#)if_dl.h 1.10 03/05/21 SMI@(#)netconfig.h 1.24 04/02/27 SMI@(#)in.h 1.55 09/05/27 SMI@(#)stream.h 1.115 08/07/22 SMI@(#)vnode.h 1.133 09/07/17 SMI@(#)t_lock.h 1.45 98/02/01 SMI@(#)machlock.h 1.25 04/07/19 SMI@(#)param.h 1.82 06/01/30 SMI@(#)unistd.h 1.43 06/03/10 SMI@(#)mutex.h 1.21 07/04/04 SMI@(#)rwlock.h 1.9 98/02/18 SMI@(#)semaphore.h 1.5 98/02/01 SMI@(#)condvar.h 1.14 04/10/21 SMI@(#)rwstlock.h 1.4 04/11/09 SMI@(#)ksynch.h 1.6 97/10/22 SMI@(#)cred.h 1.27 06/05/03 SMI@(#)resource.h 1.37 07/02/07 SMI@(#)seg_enum.h 1.9 09/07/02 SMI@(#)kstat.h 1.22 07/02/02 SMI@(#)kmem.h 1.38 09/05/07 SMI@(#)vmem.h 1.12 05/06/27 SMI@(#)poll.h 1.28 98/11/23 SMI@(#)strmdep.h 1.10 98/01/06 SMI@(#)model.h 1.24 04/09/28 SMI@(#)strft.h 1.2 00/03/17 SMI@(#)byteorder.h 1.18 04/09/28 SMI@(#)devid.h 1.14 08/05/21 SMI@(#)sunddi.h 1.180 09/06/01 SMI@(#)dditypes.h 1.41 08/02/14 SMI@(#)ddipropdefs.h 1.23 09/02/01 SMI@(#)devops.h 1.50 05/06/14 SMI@(#)buf.h 1.59 09/05/15 SMI@(#)types32.h 1.4 98/02/13 SMI@(#)as.h 1.94 10/04/07 SMI@(#)watchpoint.h 1.9 04/06/25 SMI@(#)copyops.h 1.5 04/06/25 SMI@(#)thread.h 1.156 09/10/09 SMI@(#)klwp.h 1.51 07/01/14 SMI@(#)signal.h 1.66 04/09/28 SMI@(#)signal_iso.h 1.6 03/05/02 SMI@(#)siginfo.h 1.59 04/07/15 SMI@(#)machsig.h 1.11 03/09/26 SMI@(#)faultcode.h 1.16 09/07/02 SMI@(#)pcb.h 1.25 09/10/04 SMI@(#)regset.h 1.9 06/05/12 SMI@(#)privregs.h 1.1 04/09/28 SMI@(#)privregs.h 1.3 06/05/12 SMI@(#)controlregs.h 1.14 09/06/15 SMI@(#)segments.h 1.6 07/02/02 SMI@(#)tss.h 1.5 04/09/28 SMI@(#)msacct.h 1.10 04/08/11 SMI@(#)ucontext.h 1.11 04/09/28 SMI@(#)lwp.h 1.34 04/09/28 SMI@(#)synch.h 1.41 08/02/19 SMI@(#)contract.h 1.2 04/09/28 SMI@(#)kcpc.h 1.7 07/10/12 SMI@(#)cpc_impl.h 1.13 07/10/12 SMI@(#)aio_req.h 1.7 00/05/22 SMI@(#)avl.h 1.11 06/03/10 SMI@(#)avl_impl.h 1.8 04/07/15 SMI@(#)seg.h 1.75 09/07/02 SMI@(#)hat.h 1.110 09/07/17 SMI@(#)page.h 1.181 09/06/15 SMI@(#)proc.h 1.209 09/06/09 SMI@(#)user.h 1.75 07/03/05 SMI@(#)timer.h 1.23 08/06/12 SMI@(#)utrap.h 1.1 03/04/21 SMI@(#)refstr.h 1.1 99/03/31 SMI@(#)rctl.h 1.15 07/11/26 SMI@(#)list.h 1.5 09/05/07 SMI@(#)list_impl.h 1.1 03/02/05 SMI@(#)door_impl.h 1.1 04/05/15 SMI@(#)ddidmareq.h 1.29 06/06/08 SMI@(#)ddimapreq.h 1.14 96/06/25 SMI@(#)mman.h 1.47 09/06/15 SMI@(#)ddidevmap.h 1.22 07/02/07 SMI@(#)ddifm.h 1.6 07/01/10 SMI@(#)nexusdefs.h 1.20 07/07/18 SMI@(#)ddi_intr.h 1.4 09/05/13 SMI@(#)ddi_intr_impl.h 1.11 09/05/13 SMI@(#)cmn_err.h 1.33 04/09/28 SMI@(#)ddi_impldefs.h 1.119 09/06/01 SMI@(#)autoconf.h 1.57 09/05/13 SMI@(#)obpdefs.h 1.6 06/03/10 SMI@(#)systm.h 1.144 10/05/05 SMI@(#)dacf_impl.h 1.3 03/12/09 SMI@(#)dacf.h 1.2 02/06/17 SMI@(#)ndifm.h 1.3 07/01/10 SMI@(#)ddifm_impl.h 1.9 09/01/08 SMI@(#)errorq.h 1.2 04/03/17 SMI@(#)nvpair.h 1.15 09/04/07 SMI@(#)errno.h 1.20 00/01/12 SMI@(#)va_list.h 1.15 04/11/19 SMI@(#)epm.h 1.50 09/05/28 SMI@(#)pm.h 1.24 09/05/28 SMI@(#)taskq.h 1.5 10/01/04 SMI@(#)ddi_isa.h 1.20 08/05/26 SMI@(#)ddi_implfuncs.h 1.54 08/12/01 SMI@(#)task.h 1.10 08/04/14 SMI@(#)project.h 1.14 07/09/26 SMI@(#)ipc_rctl.h 1.1 07/02/07 SMI@(#)zone.h 1.21 10/01/08 SMI@(#)pset.h 1.6 08/11/14 SMI@(#)processor.h 1.13 08/11/14 SMI@(#)procset.h 1.25 04/07/16 SMI@(#)label.h 1.3 09/06/23 SMI@(#)netstack.h 1.3 09/01/06 SMI@(#)uadmin.h 1.31 07/01/14 SMI@(#)devctl.h 1.17 08/11/14 SMI@(#)dma_engine.h 1.9 98/01/06 SMI@(#)sunpm.h 1.10 07/11/15 SMI@(#)sysevent.h 1.15 04/06/03 SMI@(#)u8_textprep.h 1.1 08/06/06 SMI@(#)libdevinfo.h 1.33 08/09/08 SMI@(#)errno.h 1.17 03/01/03 SMI@(#)sunmdi.h 1.17 08/11/27 SMI@(#)note.h 1.2 95/03/21 SMI@(#)esunddi.h 1.25 06/03/10 SMI@(#)openpromio.h 1.20 03/05/06 SMI@(#)devinfo_impl.h 1.22 06/06/11 SMI@(#)limits.h 1.59 04/08/24 SMI@(#)limits_iso.h 1.2 03/12/04 SMI@(#)int_limits.h 1.9 04/09/28 SMIacomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13@(#)stdio.h 1.84 04/09/28 SMI@(#)feature_tests.h 1.25 07/02/02 SMI@(#)ccompile.h 1.2 04/11/08 SMI@(#)isa_defs.h 1.29 08/06/06 SMI@(#)stdio_iso.h 1.8 05/08/16 SMI@(#)va_list.h 1.15 04/11/19 SMI@(#)stdio_tag.h 1.4 04/09/28 SMI@(#)stdio_impl.h 1.15 07/03/05 SMI@(#)stdio_c99.h 1.2 04/03/29 SMI@(#)errno.h 1.17 03/01/03 SMI@(#)errno.h 1.20 00/01/12 SMI@(#)math.h 2.24 04/10/23 SMI@(#)math_iso.h 1.9 04/10/23 SMI@(#)math_c99.h 1.9 04/11/01 SMI@(#)floatingpoint.h 2.9 04/10/23 SMI@(#)ieeefp.h 2.12 04/10/23 SMI@(#)stdlib.h 1.51 04/06/30 SMI@(#)stdlib_iso.h 1.9 04/09/28 SMI@(#)stdlib_c99.h 1.2 04/03/29 SMI@(#)string.h 1.27 07/01/14 SMI@(#)string_iso.h 1.5 04/06/18 SMI@(#)kstat.h 1.4 93/06/30 SMI@(#)types.h 1.86 07/09/20 SMI@(#)machtypes.h 1.11 04/09/28 SMI@(#)machtypes.h 1.2 04/09/28 SMI@(#)int_types.h 1.10 04/09/28 SMI@(#)select.h 1.19 04/01/28 SMI@(#)time_impl.h 1.11 05/05/19 SMI@(#)time.h 2.77 09/06/02 SMI@(#)time.h 1.45 08/01/09 SMI@(#)time_iso.h 1.4 04/09/07 SMI@(#)kstat.h 1.22 07/02/02 SMI@(#)systeminfo.h 1.19 04/07/16 SMI@(#)smbios.h 1.1 06/03/19 SMIacomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13@(#)string.h 1.27 07/01/14 SMI@(#)string_iso.h 1.5 04/06/18 SMI@(#)feature_tests.h 1.25 07/02/02 SMI@(#)ccompile.h 1.2 04/11/08 SMI@(#)isa_defs.h 1.29 08/06/06 SMI@(#)stdio.h 1.84 04/09/28 SMI@(#)stdio_iso.h 1.8 05/08/16 SMI@(#)va_list.h 1.15 04/11/19 SMI@(#)stdio_tag.h 1.4 04/09/28 SMI@(#)stdio_impl.h 1.15 07/03/05 SMI@(#)stdio_c99.h 1.2 04/03/29 SMI@(#)socket.h 1.78 08/01/18 SMI@(#)types.h 1.86 07/09/20 SMI@(#)machtypes.h 1.11 04/09/28 SMI@(#)machtypes.h 1.2 04/09/28 SMI@(#)int_types.h 1.10 04/09/28 SMI@(#)select.h 1.19 04/01/28 SMI@(#)time_impl.h 1.11 05/05/19 SMI@(#)time.h 2.77 09/06/02 SMI@(#)time.h 1.45 08/01/09 SMI@(#)time_iso.h 1.4 04/09/07 SMI@(#)uio.h 1.34 09/06/15 SMI@(#)socket_impl.h 1.1 05/08/02 SMI@(#)un.h 1.11 02/10/02 SMI@(#)if_dl.h 1.10 03/05/21 SMI@(#)netconfig.h 1.24 04/02/27 SMI@(#)in.h 1.55 09/05/27 SMI@(#)stream.h 1.115 08/07/22 SMI@(#)vnode.h 1.133 09/07/17 SMI@(#)t_lock.h 1.45 98/02/01 SMI@(#)machlock.h 1.25 04/07/19 SMI@(#)param.h 1.82 06/01/30 SMI@(#)unistd.h 1.43 06/03/10 SMI@(#)mutex.h 1.21 07/04/04 SMI@(#)rwlock.h 1.9 98/02/18 SMI@(#)semaphore.h 1.5 98/02/01 SMI@(#)condvar.h 1.14 04/10/21 SMI@(#)rwstlock.h 1.4 04/11/09 SMI@(#)ksynch.h 1.6 97/10/22 SMI@(#)cred.h 1.27 06/05/03 SMI@(#)resource.h 1.37 07/02/07 SMI@(#)seg_enum.h 1.9 09/07/02 SMI@(#)kstat.h 1.22 07/02/02 SMI@(#)kmem.h 1.38 09/05/07 SMI@(#)vmem.h 1.12 05/06/27 SMI@(#)poll.h 1.28 98/11/23 SMI@(#)strmdep.h 1.10 98/01/06 SMI@(#)model.h 1.24 04/09/28 SMI@(#)strft.h 1.2 00/03/17 SMI@(#)byteorder.h 1.18 04/09/28 SMI@(#)netdb.h 1.30 03/12/04 SMI@(#)inttypes.h 1.4 04/04/29 SMI@(#)inttypes.h 1.3 03/12/04 SMI@(#)int_limits.h 1.9 04/09/28 SMI@(#)int_const.h 1.5 04/09/28 SMI@(#)int_fmtio.h 1.6 04/09/28 SMI@(#)stdint.h 1.1 03/12/04 SMIacomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.497netperf.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c netperf.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0netlib.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c netlib.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0K,netsh.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c netsh.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0Bnettest_bsd.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c nettest_bsd.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0Xnettest_dlpi.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c nettest_dlpi.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0-nnettest_unix.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c nettest_unix.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0}nettest_xti.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c nettest_xti.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0nettest_sctp.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c nettest_sctp.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0nettest_sdp.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c nettest_sdp.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0lnettest_omni.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c nettest_omni.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0net_uuid.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c net_uuid.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0 netcpu_kstat10.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c netcpu_kstat10.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0Wnetrt_rtmget.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c netrt_rtmget.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0netdrv_solaris.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c netdrv_solaris.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.04netslot_solaris.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c netslot_solaris.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0KJnetsys_solaris.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c netsys_solaris.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0`netsec_none.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c netsec_none.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0GA /home/t600359/dev/netperf-2.5.0/srcnetperf.cF@ /home/t600359/dev/netperf-2.5.0/srcnetlib.cE? /home/t600359/dev/netperf-2.5.0/srcnetsh.cKE /home/t600359/dev/netperf-2.5.0/srcnettest_bsd.cLF /home/t600359/dev/netperf-2.5.0/srcnettest_dlpi.cLF /home/t600359/dev/netperf-2.5.0/srcnettest_unix.cKE /home/t600359/dev/netperf-2.5.0/srcnettest_xti.cLF /home/t600359/dev/netperf-2.5.0/srcnettest_sctp.cKE /home/t600359/dev/netperf-2.5.0/srcnettest_sdp.cLF /home/t600359/dev/netperf-2.5.0/srcnettest_omni.cHB /home/t600359/dev/netperf-2.5.0/srcnet_uuid.cNH /home/t600359/dev/netperf-2.5.0/srcnetcpu_kstat10.cLF /home/t600359/dev/netperf-2.5.0/srcnetrt_rtmget.cNH /home/t600359/dev/netperf-2.5.0/srcnetdrv_solaris.cOI /home/t600359/dev/netperf-2.5.0/srcnetslot_solaris.cNH /home/t600359/dev/netperf-2.5.0/srcnetsys_solaris.cKE /home/t600359/dev/netperf-2.5.0/srcnetsec_none.c DD% DD% DD% DD% DD% DD% DD% DD% DD% DD% DD% DD% DD% DD% DD% DD% DD%.interp.SUNW_cap.hash.dynsym.dynstr.SUNW_version.rel.data.rel.bss.rel.plt.text.init.fini.rodata.rodata1.got.dynamic.bssf.symtab.strtab.annotate.comment.debug_info.debug_line.debug_abbrev.shstrtab o !"--y)o4G4G7 BDHDHA BLHLH(J BtHtHp NKKSRR xY_e@@m[vX*X*{,,;--DDEDD̤D' hl`oȉ}b94m?v " 0707010003bb9b000081ed0000000000000000000000014f45c14a00033704000000b500010002ffffffffffffffff0000001d00000000root/usr/local/bin/netserverELFW4|24 (44oLLLL`DNN/usr/lib/ld.so.1  "#%()+-/02469:<=>ABDEIKLOQSTUWYZ[\_abcefhijknorsvwyz}   !#$&(*,.024679;>ABCDEGIJLNOPRSUVWYZ[]^`bceghijmprstwyz{|}~ !$&'*,.13578;?@CFGHJMNPRVX]^`dglmpqtux{|~   "%')+-/1358:<=?@FHKMQTX\_adfklnoquvx L %Q,$V8p VOhe PV 0 P ^ fPPW"  &3Q9TGRNw  Z^ldUs( Tt_1  e  T2 Qb4UhP.T3e@LVT _{ gy8 PQ_`# TP TdV $QtY # 0g H N f { M 4tUO s 0 @YI `x $R,<Ѐ*  HeUV a i vY sPdj  QRI tWUP OJT'6^K?  K\P{Q hLm  3 0, tQP ,  &Q 9 K` W0] gQo PQe $RT  ) $WS,@ n &TP @ NxPh$TldPv| p 8 L $U @_LgWV$ X_&  7QQV_X hVovk l E UQШ: PX{ pY TTp> 0  p   x  eL+ 0 5 @c ? `@ O UX ^k Ur V} O P Ѓ pP! P `r S    <! `_4 \ >  K P [ Wh P tV p_ P  P} 2 S  `= O dW tA   t 2 \_? & W ^  o  ~ O! S> W <\y O ` H  ( M w R < uy D # ^5 S? * V2TQL x- S dSY 8P`   q dRv  `| .` P =  p  U HP`r% d  ! М 5 ^H DSb !R 8` XP{ P `P P R V P[DP  @b Q00' =QVV]p mp }^ GR ^Rjy Tv x_tSt Q@X pj' Q (_P"4S*LP9QLTW* T c[  a0p^% 0  SPP8_   tTP_.8VG0JІ . X`  FDQaY lDVwL_] 4QPxq # lP NO@!  N  @H_0_(P1 EЭ 'H!Sp` bDWoQzP @uY |RP d} $  P6 dQ&8 establish_control_internallsr_sizelistenkstat_closeget_sockaddr_family_addr_port__longdouble_usedalloc_sendfile_buf_ringatexitfwriteremote_machineset_sock_bufferget_cpu_methodoutput_rowresult_brandkeep_statisticsmulticast_ttlmeasured_sum_result_get_exit_frame_monitorunknownprogrammsec_sleepgettimeofdayfprintfsend_tcp_cclocal_recv_offsetstrtodinterval_watepowrsp_sizelibmainconfidence_iterationsfind_egress_interface_by_linkrem_tcpcorkget_sock_bufferstrtokget_uuid_stringprint_netserver_usagestrtolmeasured_var_resultsqrtlss_size_endremote_interval_burstlss_sizecatcherremote_send_alignlocal_sysnamemeasured_var_local_service_demandprocessor_bindprint_sockets_usagebreak_args_explicit_sep__xtoldump_addrinfomkstemp64ioctlchmodnsec_enabled_to_strset_defaultscalc_service_demand_fmtset_sockaddr_family_addr_portcalculate_confidencenetlib_initnst_to_hstrem_clean_countgetprotobynamesuppress_debugestablish_controlcalibrate_remote_cpuget_remote_system_infounlink_empty_debug_filescan_cmd_linestrncpylocal_cpu_usagerecv_tcp_rrlsr_size_enduuid_create__ctypeinet_ftosclose_listensget_result_confidsetsidlib_local_cpu_utilcalc_service_demandsmbios_open__fsr_init_valuesendfilev64measured_sum_remote_service_demandnetserver_idfreeaddrinfoserver_controlnetsh_idlisten_portconfidence_levelmeasured_square_sum_remote_cpuremote_data_addresscomplete_addrinfosrequest_array_etextscan_netserver_argsscan_sockets_argsHIST_purgestrduprsr_sizeverbositylib_remote_maxratelib_num_loc_cpusremote_data_familyformat_cpu_methodHIST_reportset_server_sockfopen64remote_cpu_usagemeasured_mean_remote_cpudisplay_confidencetest_namemeasured_failssend_udp_streamcomplete_addrinfodi_prop_intssigactionlib_local_maxrateget_idsend_request_n_PROCEDURE_LINKAGE_TABLE_cpu_util_initmeasured_square_sum_local_cpu__fpstartlocal_releasesend_response_nrecv_tcp_maertsnetperf_responsestrcasecmpHIST_newnf_to_af_GLOBAL_OFFSET_TABLE__edatasmbios_info_commondi_prop_nextwherefirst_burst_sizeremote_data_portmeasured_mean_remote_timedi_minor_namerss_sizecallocoptindaccept_connectionsrecv_sizesum_rowbzeroloc_nodelaymemsetidentify_local__fsrhst_to_strbind_to_specific_processorcreate_data_socketwant_daemonizewait_time_secsnettest_idinit_statset_fdsetrecv_udp_streamrecvfromremote_send_offsetstrchrkstat_open_environ_exitallocate_buffer_ringmeasured_sum_local_cpumeasured_var_remote_service_demandcalibrate_local_cpurewindresponse_arrayHIST_search_bucketFileNamersr_size_reqlocal_host_namelib_use_idleparse_directiondi_prop_namemeasured_sum_local_timestop_itimerreq_sizestat64fill_filestart_timercalc_thruput_omnifreadcalc_service_demand_internaldaemon_parentsysinfonsec_type_to_strremote_sysnamenetlib_get_page_sizerss_size_reqHIST_timestamp_stop_addoptarglib_num_rem_cpuslocal_data_portnetperf_usage1smbios_closenetperf_usage2listen_listcpu_start_internaltest_transremote_versionHIST_clearhtondchdirtimes_upinet_ptosset_hostname_and_portlocal_send_offsetsigaddsetset_nonblockrand32htonllibfmtrecv_tcp_conn_rrforkdemo_moderetrieve_confident_valuesmeasured_mean_local_cpucpu_startnetperf_requestlocal_address_familyhtonslocal_proc_affinitylocal_send_alignHIST_timestamp_startrecv_response_timedremote_recv_offsetsetitimeriteration_minmeasured_square_sum_resultsend_requestmeasured_mean_resultmeasured_mean_remote_service_demandstrcmpdi_binding_namemeasured_sum_local_service_demanddi_initprint_top_test_headermeasured_var_local_timedump_requestmeasured_mean_local_timememcmplocal_test_portset_port_numberresult_confidence_onlycpu_stop_internalnetlib_controlinet_ntonrss_size_endrem_rcvavoidinet_ntopkstat_lookupsigemptysetrecvremote_interval_usecsfree__environ_lockgetoptinstall_signal_catchersopen_debug_filenetperf_daemondump_responsesprintfperrorshutdownformat_numberremote_send_widthparse_protocolrsr_size_endsend_tcp_rrremote_cpu_ratetime1get_num_cpusnetlib_idtime2nettest_sctpselectcalc_thruput_interval_omnicpu_util_terminateloc_cpu_ratelib_cpu_maplib_local_peak_cpu_idget_local_system_inforecv_response_timed_nnettest_sdpstrcpygai_strerrorsrand_nunamerouting_allowedformat_units_xmknodparse_socket_typedi_prop_typerecv_responseerrnoHIST_timestampconvertmemcpybreak_argsiteration_maxloc_rcvavoidatofHIST_get_stats__assertatoirecv_request_ncpu_stopgetaddrinfonetperf_versiondemo_intervalconnectget_loc_cpu_confidsnpuidtoupperloc_tcpcorkkeep_histogramrecv_tcp_cc__iobrem_nodelaystop_timerlib_local_per_cpu_util__1cG__CrunMdo_exit_code6F_v_netlib_init_cpu_mapdi_minor_nextaf_to_nfconvert_timespectest_timerecv_response_nprotocol_to_strtest_bytesHIST_get_percentilesendfile_tcp_streamfind_driver_infosendtolocal_connectedshutdown_controlprint_headersHIST_new_nsend_tcp_conn_rrlocal_machinenetcpu_kstat10_idlocal_recv_alignmeasured_sum_remote_cpustart_itimersetup_listensparse_address_familylocal_cpu_ratespawn_childfind_interface_slotfind_security_infosend_udp_rrloc_dirty_countgethrtimemeasured_square_sum_remote_service_demandstrlencmd_filestrstrmeasured_square_sum_local_service_demandlib_remote_peak_cpu_utilntohd_lib_versiondelta_microfind_interface_idsrem_dirty_countidentify_remotespawn_on_acceptsend_tcp_streamntohlsend_tcp_maertsgetsockoptcommand_lineshell_num_cpusgetpidntohscalc_thruputcalc_thruput_intervalfind_egress_interface_by_addrremote_proc_affinitysignalnot_inetdloc_sndavoid__udiv64get_rem_cpu_confidbreak_args_explicitfcntllib_remote_cpu_utillib_elapsedgetsocknamerecv_udp_rrsend_responseremote_connectedloc_clean_countlocal_data_familyunits_this_ticklib_local_peak_cpu_utilrem_cpu_rateaccept_connectionsetsockoptremote_recv_widthunlinksysconfcontrol_familylocal_data_addressdi_finidump_globalstest_len_tickscpu_binding_requestedprint_netperf_usagerecv_tcp_streamlocal_versionalarmmeasured_square_sum_local_timemeasured_mean_local_service_demanddemo_unitsinterval_countsendwant_keepalivesend_sizeif_indextonametzaccess_bufferHIST_addhst_to_nstkstat_readlsr_size_reqcreate_listensfflushrandom_ip_addressfind_system_inforemote_recv_align_DYNAMIC___Argvcalc_cpu_util_internalrecv_requestmeasured_local_resultslss_size_reqsnprintfcalibrate_idle_ratecalc_cpu_utilremote_releasedi_walk_nodeno_controlmeasured_var_local_cpuresolve_hostinet_ttosrem_sndavoidmallocmeasured_var_remote_cpusend_tcp_mssprocess_requestslib_remote_peak_cpu_idfind_egress_interfacefilenousernamelibsocket.so.1SUNW_1.4libnsl.so.1SUNW_1.7libkstat.so.1SUNW_0.7libsmbios.so.1SUNWprivate_1.1libdevinfo.so.1SUNW_1.1libsendfile.so.1libm.so.2libc.so.1/ '= >G '= S\ (= js qN  '=  '=  '= '= qN O^HYL@LLZLLL<LLLLLLoLL7LLMMMe MMMMM5M M$M0(M,M0M4Mt8MtNxxNN|NNNNSNNN5L%L%Lh%Lh%Lh%Lh%Lh %Lh(%Lh0%Lh8p%Lh@`%LhHP%LhP@%LhX0%Lh` %Lhh%Lhp%Mhx%Mh%Mh% Mh%Mh%Mh%Mh%Mh% Mhp%$Mh`%(MhP%,Mh@%0Mh0%4Mh %8Mh%ЋEPRE PEPhLhXhh<jhhj jEP] EEEEEEjjEPEPE PEP/EЋE@EԋEЃu< t&hLhhh jhh-jjEЃuEԃ~EЃtN tEEHEE8EE(EE}t吃tt؋EtjE Ph| EtjE Pha EPE PEPK OtZEtE EEjEPwjPE PEPhhX~jhXbEt EEEjEPjPE PEPh,hh&jhhjj;ÐU]hjE P+ EEE t2jE PEPhihl$Pj$P2EE@;E~ E@E t*E@Ph$P^ j$PE@E EUE@R ӋEPE@EEoEEE]U t(hsh4$P j$POEEEt"Ej@PE@EEuÐU,]ԡ t(hh4$P\ j$P4u.oL Ou @  u%1 t H L 1jhEjhEjh|EjhjEL YEEEDP8 PDEDP| P%EDP8PEDP PugED@E؋EDXEDHEDP PR8PQ| PS8 PEPhhhT =,E@EEEubEHEEDXEDHEDPED@hPhRhQhShhhT ,jj..L $]E䛃$H]E]jEPhT  jhhX  t5EjP$h$Pvj$P/E:."0F Ph$P j$PnP .}B}|띐 } 댃 / >u^}+}I\G"E=,}^/=,=XN]ÐU t(hh4$P j$PbjhHSjhXDjhh5j$P%jjjPcjPRhh,$PPj$PjjdjOP0h0 jj* bt琐ÐU Dž t(hh4$P j$P"DžEPPEP DPuOjP*jPRhhL$Pj$Pjj+jjPjhDPPk tjDPP+ÐUl t(hh4$Pv j$PhjP hjPz EPOP$||jjPPEPBP:xDžtxt;|ttD#Ãt^jtPtDpptҋK#ʋpHxHxt@txtt;|Px}OjPjPRhhp$Pj$P[jjTlÐU t(hh4$P| j$PhE PEP EEijjb @ OO@ 5 @ @ PPPc thPh tjPbp jP^^=~2hhhh3 jhhjjHJO 1j Ph B @  p p jP, h$hjjEV}HD}6} 4t6t?~L} D"nLONZh}'d}VyEdf.p}hnupvhE PEP EE]ÐU t(hh4$Pr j$PjhHjhXjhhjPjPRhh,hhjhh~jjjh,cfjjjjjtڐÐU t(hh4$P\ j$P@ tIDžPPj u @ @ ÐUE j@Pj@Pujh4&EE @PPR6AhhXh p j h\h  E PEPtc@Ot ]/p Ph h tA,EEUjjEPE PEPjEEÐUjEPSEEÐUjEP3EEÐUjj %EEÐU EEEEEPEPj tjhdjjÐU<xEAE5E)EEE@w$tEÈttttU$xE)EEEtԃt吋EÐU0EAE5E)EE} tÃttِEÐULEaEUEIjjEPh,j h  E!E}tɐt=t뺐EÐU0@EAHE5TE)`EE}t吃tǃt؋EÐUE|jE PEP EuEaE|jE PEPi E=E)|EEptِEÐUjjuEEE EEEE EjEPEjEPEEE8EDEE+EU@DU+UEBE@EE~ȋEEEEEÐUjjeuEEE EEEE EEE8EDEE+EU@DU+UEBE@EE~jEPEjEPEEEEEEÐU]XEE]ÐU ]BE@EEj@PmEE غH BEE |E ~/hl$P"j$Pjj6Ej@PEEЋ]#,#E ؉]E%=tjEPЋEPE@EEEE | E =~/h$Pxj$PjjEEUEjPEȋUE EU +ЉUE s EEE EEEv EE EEEEغH BEUEMы##E ؋UEUEjPȋUE E@EE+WE@Ph$PU j$PjjiE@p뮐]ÐUjjEE=~jjPhh$Pj$PdjjhjxP jjPhh$Pj$P蜽jj0jjjEPEPjjPhh$P芸j$P jj螷EuK t#h,$PIj$PɷjDPP9EE;E}B ~EPh`$P j$Pmjj ~HPHPtjHPPEEEÐUjjQEEÐUTEL EEEEEE } E@ E EE@v; ~*EPh$P j$PnE@EE@sUE@EE@rhjdPԶ jP٪jjPPhx$P˪j$PKJ t>jP荪jjPPh$Pj$PE@EEuEEE@EjEPQENE@LPjEP茭jEP~EtCjjE PEPh $Pj$PgLPEEEE]ÐU]EPEPEPEPE PEP‚]P  th$P>E@P E@X E@E@  E@E@E@PEP\E@  E@$|OP P Ph$P= jh =j$Pe=jj<UE@PBPEPA ujh k=jj<h tF<EQuh jPcijh POijh!>jjT<jP`tjd_Pv<pUjjjl PBPEP?EԋEԃBH ~#hh$Pp<j$P;jh_P̩h_Pd_Pة;},jh_P蠩h_Pd_P謩;|ԡd_l_h_d_l_h_E@EЋE؋@E؋Eȃt E+EԉEȋEԋUEUEU<u.Ujjjl PBPEP>EԋEԃEԃ| u6Qu,jhH!;EPh\<jjZ:, ~EEPEPjEP=ujhl!:jj :gEPPPjEP:QLP u" th!$P|:QP P Ph$PT: jh!:j$P9jjY9UBPBP`ݝt݅t]9EUtx߭ty-ݝt݅t]EPEPFݝt݅t]u Wٝtمt$ٝtمt]ٝtمtٝtمtjj$$EPEPkٝtمt]0ٝtمt]ٝtمt] tSE@EٝtمtEj@PEP$EPEPߖٝtمt]0ٝtمt]ٝtمt]_ٝtمt]ٝtمt]ٝtمt]ٝtمt]jjEPEPEPEPEPEPEPgP(g@gQzsg;<g;8EPEPEPEPEPEPkQzs<~Uu jPPugEj@P:ugytV4 u ^u!E ^EEgEPR$EP$P6R4 u ^u !E ^EEgEPR$EP$P364 t,uggjPRQEP$P54 u ^u!E ^EEEEEEEP$$$$EPEP$PT PP PEP$Pm5H, w$4 u ^u !E ^EjEPEPEPEP$P54 tUtPEP$P4 4 u ^u!E ^EEܛEPEPEP$PX PL PEP$Pu4(, w$, EЉtۅty-ݝt݅tEE@tۅty-ݝt݅tEEj@P$EP$EPEP^P^PlPPhhhEP$P3HEPEP$P3 j$P3dLLU,!E!EEET ET EjjjEPEPEP4 tEPEPh! jEPEEujh82jj1 thl$P2Q E\_PE`_PEl PEPElP E^PE PEPh tEh P E< P E P$E|P(jh @3ЋEP4Ej@PЋEP8 ~h"$P1u1}P  th$P]1E@P E@X E@E@  E@E@PEP;E@  E@$|NP P Ph$P0 jh8"0j$PE0jj/UE@PBPEP3 ujh<"K0jj/EEPEPTjEPZ04 u ^u p"E ^EjjEPEPEP$P/y4 tEPh$P/ 4 u ^u t"E^EjjEPEPEP$P/, w$!!L!L!UE@ELEpEEEEEEEEEhT dT `jEPF3jjjEPEPEPX4 tEPEPhx" Eg@Qzs g;<|g;8 EEE<jEPE̋Ẽujh"-jj - th"$P-u T ~ T  D u'T =@D D u D @D E؃u'jj^PdPPD PcEءt"j`PKٝTمT` h\_Ph`_Phl PhPhlP h^Ph PhPh thh P h< P h P$h|P(jh -ЋhP4Ej@P3ЋhP8 ~h$P+pwP  th$P+d@P d@X d@d@  d@d@PEPd@  d@$|OP P Ph$P(+ jh"*j$P*jj-*UE@PBPEPC. u;jh*EjP/Ph$/,jj)h t&<Ejh PV< E<jP蝂tjd_P賗<t EȃE؋@lDžpE؋P@ txE؋@|jjEPjlPEPS.EԋE;tdEԃ} u_jh"\)jjPEPh#hhl)jhh(jj(H ~#hh$P )j$P(jh_Pih_Pd_Pu;},jh_P=h_Pd_PI;|ԡd_l_h_d_l_h_E@EЋE؋@E؋Eȃt E+Eȡ<4Eȃ(, ~EEPEPjEP+ujh'jj 'EjjjjPEP*EPPOjEP'YsP u th!$P'NP P Ph$Pd' jh<#%'j$P&jji&`BPBPMݝL݅L]EPEP菁ݝL݅L]u \ٝLمL$8ٝLمL]ٝLمLٝLمLjj$$EPEP贄ٝLمL]1ٝLمL]ٝLمL] tW`@EٝLمL`j@PEP$EPEP!ٝLمL].ٝLمL]ٝLمL]_ٝLمL]ٝLمL]ٝLمL]ٝLمL]jjEPEPEPEPEPEPEPgP@(g@gQzsg;<g;8nEPEPEPEPEPEP诠Qzs<~虡u jPbg`j@P{bgtZ4 u ^u@#\ ^\Eg\PR$EP$P#Z4 u ^uD#\ ^\Eg\PR$EP$Pe#4 t,bggjPRQEP$P)#4 u ^uH#\ ^\EEEEE\P$$$$EPEP$PT PP PEP$P"H, w$04 u ^uL#\ ^\j\PEPEPEP$P%"4 tyaPEP$P! 4 u ^uP#X ^XEܛXPEPEP$PT PP PEP$P!(, w$0, EЉLۅLy-ݝL݅LE`@LۅLy-ݝL݅LE`j@P$EP$EPEP^P^PlPdPhhhEP$P HEPEP$P j$P $---.(/(/ULT T  t#hT#$P j$P t#h|#$Pj$PpL  t#h#$Pj$P9 t-@ Ph#$P j$P@H_@L_@@$ @(j@8P费Ћjj@4PRPP=j@8PyjjjPPPP5jPuP ;djj@u%L ~L l  l @l  u'L =l @  u  @ jj@PB Pl P PdP t#h$$Pj$P5jPDu,P jP(cjjDžPPP u,P jP,bjj;jPI!ЋPP ٝمX@t=@ j@P{ٝمX@ T PL PP P P$l PaDžPPP ujPjj<@ jPGj@PsDž<jjjl PBPP2uP `jj'ۅ܅ݝ@@<u:jjjl PBPPgjPcuP `jjPBPr tOjjPPh@$$P Ph`$$P j$PqPPg@ݝ݅XP PPP@t7ٝم$uٝمX tgh$$PjPPPh$$PPh$$P j$PQu^jPjPÐULT T  t#h%$P7j$P t#h0%$P j$PL _ t#h`%$Pj$PS t-@ Ph%$P j$P t#h%$Poj$P@H_@L_@@$ @(j@8P衱Ћjj@4PRPP*j@8PfjjjPPPP"jP{uP (\jj@u"T ~ T  @D u'L =@D D u D @D jj@PB PPD PTH t#h%$Pj$P%jP4u,P jPt[jjDžPPP u,P jPZjj+jP9ЋPP ٝمX@t=@ j@PsٝمX@ T PL PP P P$PYDžj@ P?j@PlPPP ujPjjDžDž<<jjjPBPPK;t3} uYP Xjjۅ܅ݝ@@<WjPvuP +XjjjjjPBPPAPBPj tOjjPPh&$PPh<&$P j$P_PPU8ݝ݅XP P@t7ٝم$mٝمX tgh\&$P!jPPPh&$PPh$$P j$P]PPcVjPjPÐU$&Eh'E@E(E4(E@(E4)E(*EE܍+E؍4(Eԍd+EEDžlDžhxT tT pjjjEPEP|PL4 t|PEPh\,z EEg*Qzs g;<|g;8F EEE<EEDžlDžhD u D  u  Eu'jj^PdPp_PD P$AEEu'jj^PPt_P P@EjEPDEEujhx,jjb  th,$Pt"j`PmٝLمL`Q= x`_Px\_PxlPx^P xPx^Pxp_Pxt_PxP x P$xP(x P0x|P4h txh P,H ڋxP,jh ?ЋxP8|j@P輧ЋxP< ~h,$P P'XP  th$PS t@P t@X t@t@ t@t@P|PQP P Ph$P jh- j$P9 jj ||@PBPEP ujh-9 jj h t$<Ejh P>7< E<jPYctjd_Pox<t EX_l;hl;X_ t)jX_PhPlPh(-$Pn Ujjjp_PBPEP EċE;p_tjh\- jjV l@lX_~ l;h}l;X_NUjjjp_PBPEP EċE;p_t>t uE~jh-` jjE@El@lt_EE@EE~wjjjEPEPEP; EEtEu0u E7jh-jj(E+EEEEEEE@ElHlh;X_}@h@h t)jlPX_PhPh-$PzẼtIH ~#hh$P'j$Pjh_Puh_Pd_Pu;},jh_PWuh_Pd_Pcu;|ԡd_l_h_d_l_h_E@EEtEHE ~9Edƒu'EPh.$PN j$P<]EQEPP_QuRP u" th!$PQP P Ph$P jh.uj$P%jjp_Et_U‰LۅL]EٝLمLuݝ@݅@]u hٝ@م@$bٝ@م@]E ٝ@م@ٝ@م@jj$$$cٝ@م@].ٝ@م@]ٝ@م@] t_p@EE ٝ@م@pj@PEP$$fcٝ@م@]/ٝ@م@]ٝ@م@]_ٝ@م@]ٝ@م@]ٝ@م@]ٝ@م@]jjEPEPEPEPEPEPEPgP{(g@gjEP/Qzsg;<g;8EPEPEPEPEPEPQzs<~πu jPAgpj@PAg\tZ4 u ^u .d ^dEgdPR$EP$PZ4 u ^u$.d ^dEgdPR$EP$P4 tb8Pxu*ggjjPREP$P[.AggjPRQEP$P+8PxuE`EdJp_t_@ۅ@MjjPP$\ݝ@݅@ݝ`4 u ^u(.\^\EEEEE\P$$$$dP`P$t_Pp_PL PT PEP$P#LjjP PX PEP$P, w$S78PxuE`EdJp_t_@ۅ@MjjPP$S[ݝ@݅@ݝ`4 u ^u,.\^\j\PdP`PEP$Pd4 t>8PxuEX EXJ?PXP$P 8PxuETEXJp_t_@ۅ@MjjPP$?Zݝ@݅@ݝT4 u ^u0.P^PEțPPXPTP$t_Pp_PL PT PEP$P,jjP PX PEP$P, w$S, 68Pxu m8PX_~ X_d Džd=u d@@ۅ@p_MjjPP$۽4Xݝ@ۭ4݅@t_MjjPP$۽4۽(Xݝ@ۭ4ۭ(݅@$Ƀ$EPEP$^P^P^PdPSEP$Pn<$MNNhP4Q4QU4.E.E.E4/E0E0E|T xT tjjjEPEPEPv4 tEPEPh0觩 Eg^lEEEEEQzs g;<|g;8EEE<jEPEEujh0jjuHT ~4T =}T p Džpp D u D  Eu'jj^PdPPD P-Et"j`PXZٝlمl`Qu|`_P|P|x_P|lP |^P| P|P|h P | P$||P(jh Ћ|P,Ej@P\Ћ|P0I>EP u" th0$P(P jh1jjx@PEPx@P x@X x@|_tjUE@PBPEP ujh$1>jj. t#hP1$PBj$Ph t<jh P%$h|1$Pj$PxjP$Qtjd_P:f<|_t%UjjjPBPEPE-MUE@PBPjPAPEPEE;tLE} u'=u E@Ejh1jj$E@EE@EH ~#hh$Pj$P jh_Pdh_Pd_Pe;},jh_Pdh_Pd_Pd;|ԡd_l_h_d_l_h_<\EPP|OQBP u th1$P&P jh1jjjt@EE䉅dۅdy-ݝd݅d]E]Edۅdy-ݝd݅d]EPEP{Pݝd݅d]EPEP[Pݝd݅d]u \ٝdمd$Rٝdمd]ٝdمdٝdمdjj$$EPEPSٝdمd]̛1ٝdمd]ٝdمd]̛ tWt@ Eٝdمdtj@PEP$EPEPRٝdمd]ț.ٝdمd]ٝdمd]ț_ٝdمd]ٝdمd]ٝdمd]ٝdمd]țjjEPEPEPEPEPEPEPgP k(EEEEEEEE܉EEE]g@gjEPQzsg;<g;8EPEPEPEPEPEPHogUH+EgUH+EgUH+EܡgHdۅdE]Qzs<~ou \jP0gtj@P0gt*E̛gjP$EP$P7(EțgjP$EP$P 4 t,a1ggjPRQEP$PEEEEEEț$$EPEPEP$P P$$EPEPEPEP$PT PEP$PZ`, w$`jjEPEPEP$P4 tm0PEP$P EE؛jjEPEPEP$P PEPEPEPEP$PT PEP$PH, w$`j$P^@_@_`4`4`UDDžDžDžT T  t#h1$Pj$Po ~#h2$Pj$PBL  ~#hD2$Pj$P  ~-@ Pht2$PT j$P u  jj@PB PAP P!E ~#h2$Pj$P` ~#h2$Pj$P3@L_@$ @(@|_j@0PЋjj@,PRPP|j@0P踈jjjPPPPtEjEPӖuP 3jj@ B DžPPP2 u,P jPr3jjjPЋPP ٝمX@@t7@j@PKٝمX@@ h T PL P PP2j@PD<h jP6 t#h3$P j$P|_ DžUPPjPBPPh;t0u%tP 91jj@E@EPPP u,P jP10jj@ t#h03$Pj$Ps<|_t,UjjjPBPP*UjjjPBPP,;t5u%tP /jjh'@E@E<: t*PhX3$P j$PkPBPNB<tمٝ t0م$h|3$Ptj$P‰ t*Ph3$P% j$PL jPЋPPPPP@t*jP EٝمX ٝمX ~#h3$P?j$P-jP)U&Eh'E@E(E4(E@(E4)EE3E܍4(E؍ET ET EjjjEPEPEP+4 tEPEPhD4\ EEEE<gVQzs g;<|g;8l EE<ED u D  u  EЃu'jj^PdPp_PD PEЋẼu'jj^PPt_P PEjEP2EEujh`4jjP th4$Pt"j`PEٝlمl`QE`_PE\_PElPE^P EPE^PEp_PEt_PE P$EP(E P0E|P4h tEh P,H ڋEP,jh fЋEP8Ej@PЋEP< ~h4$P(W0P ue th$PE@P E@X E@ E@E@PEPpQP P Ph$P jh4j$Pjj!UE@PBPEP7 ujh-jjh t&<Ejh P< E<jP;tjd_PPEE;X_}ZUjjjp_PBPEP@EȋE;p_tjh4jjE@EE;X_|<t EUjjjp_PBPEPEȋE;p_t*ujh5DjjEЋ@EЋUjjjt_PBPEP@EE;t_t*ukjh45jj8E̋@E̡H ~#hh$Pj$P;jh_POh_Pd_P#O;},jh_PNh_Pd_PN;|ԡd_l_h_d_l_h_E@EċEtEHE ~9EĹdƒu'EPh.$P j$Pb<EEPP29Qu@,P u" th!$PpQP P Ph$PH jhT5 j$PjjMp_Eċt_U‰EEٝlمluݝ`݅`]u dٝ`م`$(<ٝ`م`]E ٝ`م`ٝ`م`jj$$$=ٝ`م`].ٝ`م`]ٝ`م`] t[E@EE ٝ`م`Ej@PEP$$ =ٝ`م`]1ٝ`م`]ٝ`م`]_ٝ`م`]ٝ`م`]ٝ`م`]ٝ`م`]jjEPEPEPEPEPEPEPgP(U(g@gjEPQzsg;<g;8EPEPEPEPEPEPYQzs<~sZu jPngEj@PXgGtV4 u ^uX5E ^EEgEPR$EP$PR4 u ^u \5E ^EEgEPR$EP$PO4 tb8Pxu*ggjjPREP$P .kggjPRQEP$P8PxuEEEEIp_t_`ۅ`MjjPP$S6ݝ`݅`]4 u ^u`5| ^|EEEEE|P$$$$EPEP$t_Pp_PL PT PEP$PLjjP PX PEP$P, w$x'8PxuEEEEIp_t_`ۅ`MjjPP$5ݝ`݅`]4 u ^ud5| ^|j|PEPEPEP$Pb4 t>8PxuEx ExPxP$P 8PxuEtExJp_t_`ۅ`MjjPP$ 4ݝ`݅`ݝt4 u ^uh5p^pEԛpPxPtP$t_Pp_PL PT PEP$P,jjP PX PEP$P, w$xj$P, ~HtuuvhwhwUDT T  t#hl5$Pj$P} t#h5$Pj$PPL  t#h5$Pj$P tfjj@ PBPh5$PTjj@PBPh 6$P)j$PD u D  u  jj@ PBPAP PM Ejj@PBPAPD P E t#hX6$Pnj$P t#h6$PAj$P@H_@L_@0 @4j@$Pj$PjhP EEuhPh4>øjjg tfjj@ PBPhH>$Pjj@PBPh>$P׶j$PWUP@HJ#Ћ@ ‰UP@HJ#Ћ@‰ t#h>$PRj$Pҵ t#h>$P%j$P襵@H_@L_@ @0 @4j@t(h8$P|j$Pjjj@PPPquXu3Džh8$P j$P良P cjj@t H t*Ph?$P華 j$PjP~<PB$Ptمٝ t*Ph@$P j$Pv@BЋPPP @$t'jP ٝمX t#h@@$PQj$PѭÐU&E.EL9E4(Ex9El:Et:E4(E:EEEET ET EjjjEPEPEPFO4 tEPEPht@wZ EEE< th@$P=t"j`P? ٝ|م|`,E`_PE\_PElPE^P EPE^PEp_PEt_PEP E P$EP(E P0E|P4h tEh P,H ڋEP,jh 袭ЋEP8Ej@P%GЋEP< ~h@$PP E@P E@X E@E@ E@E@PEPP tHh$PtjEPOPh@$PO j$PϪPP P Ph$P jh@٪j$P艪jj腪jP]_+_t& _+ _‹_‰E _EEHEh t#<Ejh Py< E<jP<t Eă!E@EE;_|_EjEPMU;uE@E t#E̹dƒuEPh;MEPEPNjEPREȋEȃujh@djj踨UE@PBPEPά EEuuuE;jh- jEPLPEPh;虪 jEPLPh,AzjjjjjEPEPEPԫEEunE@E̋EătEHEġ ~=jEP7LjjPEPh3jjנ tfjj@ PBPhB$Prjj@PBPh@B$PGj$PǠUP@HJ#Ћ@ ‰UP@HJ#Ћ@‰ t#hxB$P j$PB t#hB$P蕠j$P@H_@L_@ @0 @4j@jEPgP;q EEu9jhxLmЋEPE @jgPpE@xEE@tEEEPhLlu$Ej@ PlЋEPE+EPhL^luEU @ BEE0EEEEHEE{EujhLlЋEPEu E @jgPoÐU4j%EPhq E̋Ẽt`hLEPnEhLjnEЋEЃtjEPkЋEPjEPmkЋEPjhLTkЋEPÐU(jjEPjhjxpE;EujEP)TEPhEPVp E؋E؃ujEPjЋEPjEPjEP'pÐUjEPREPE PUE@E @jhLQjЋEPUWVS[d[^_UWVS[ñd[^_open_debug_fileset_server_sockcreate_listenssetup_listensset_fdsetclose_listensprocess_requestsspawn_childaccept_connectionaccept_connectionsscan_netserver_argsdaemonizecheck_if_inetd?netperfnetperfXXXXXX@ @@@resolve_host.A@@ A$@Y@j@cAxi)@ʡE6@~jt @h|?5@ rh@~jt@Q@ r@jt@m@S㥛@;On@HzG@)\(@?5^I @(\@zG@+@X9v@㥛 @p= ף@d;O@Zd;O@Pn@{Gz@ r@"~j@Mb@\(\@tV@jtO@#@w/]@"~j@T㥛 @- @ˡE @ףp= @ @'1Z @ +@q= ףp@jt@7A`@~jt@|?5^@v/@/$@S@(\@S@Zd;O@~jt@K7A`@K@Zd;@^I +@v@?5^I @@?Y@?create_data_socket{Gz??@.AO_@?@ @?Y@PGO_@?@%s_%d/tmp/netserver.debug/dev/nullwnetserver: debug filer%s: opening of %s failed: %s (errno %d) %s: close of STDIN_FILENO failed: %s (errno %d) %s: dup of rd_null_fp to stdin failed: %s (errno %d) %s: close of STDOUT_FILENO failed: %s (errno %d) %s: dup of where to stdout failed: %s (errno %d) %s: close of STDERR_FILENO failed: %s (errno %d) %s: dup of where to stderr failed: %s (errno %d) %s: enter Yo, Iz ain't invalid! %s: called with host '%s' port '%s' family %s(%d) %s: Sleeping on getaddrinfo EAI_AGAIN %s: could not resolve remote '%s' port '%s' af %d getaddrinfo returned %s (%d) %s could not allocate a socket: %s (errno %d) %s: warning: could not set SO_REUSEADDR: %s (errno %d) %s: could not malloc a listen_elt %s: warning: bind or listen call failure: %s (errno %d) ::00.0.0.0Starting netserver with host '%s' port '%s' and family %s IN(6)ADDR_ANYUnable to start netserver with '%s' port '%s' and family %s %s: enter list %p fd_set %p setting %d in fdset |,_;%c%s%c%s%c%s%c%sNoDelimUniquenetserver: sending CPU information: rate is %g num cpu %d unknown test number %d %s: fork() error %s (errno %d) %s: accept failure: %s (errno %d) %s: select failure: %s (errno %d) DdfhL:n:Np:v:V46netserver: This version can only support %d CPUs. Pleaseincrease MAXCPUS in netlib.h and recompile. Netperf version %s 2.5.0/tmp/malloc for program name failed! 12865netperf: setitimerUnknownDisabledPermissiveEnforcingUNKNOWN MODESELinuxUNKNOWN TYPESOCK_DGRAMSOCK_STREAMSOCK_SEQPACKETSOCK_UNKNOWNIPPROTO_TCPIPPROTO_UDPIPPROTO_SCTPIPPROTO_UNKNOWN(%d)AF_INETAF_INET6AF_INET_SDPAF_UNSPECMask length must be between 0 and 32 inclusive for AF_INET Mask length must be between 0 and 128 inclusive for AF_INET Unexpected Address Family of %u Sorry, this system has more CPUs (%d) than I can handle (%d). Please alter MAXCPUS in netlib.h and recompile. netperf: caught SIGINT catcher: timer popped with times_up != 0 installing catcher for all signals Could not install signal catcher for sig %d, errno %d About to start a timer for %d seconds. start_timer: error installing alarm handler errno %d error starting alarm timer, ret %d errno %d setting the interval timer to %d sec %d usec test len %d ticks UnknownSystemUnknownReleaseUnknownVersionUnknownMachine2.5.0netlib_init: request_array at %p netlib_init: response_array at %p KMGkmgusrCould not open requested fill filewidth >= 1netlib.cmalloc(%u) failed! malloc(%d) failed! This was here to try to avoid dead-code elimination %d allocate_sendfile_buf_ring: incomplete writealloc_sendfile_buf_ring: could not allocate temp namealloc_sendfile_buf_ring: could not allocate buffer for filealloc_sendfile_buf_ring: Could not open requested filealloc_sendfile_buf_ring: could not stat filealloc_sendfile_buf_ring: specified file too small. file must be larger than send_width * send_size request contents: %d: %8x %8x %8x %8x |%4.4s| |%4.4s| |%4.4s| |%4.4s| response contents %d: %8x %8x %8x %8x >%4.4s< >%4.4s< >%4.4s< >%4.4s< %-7.2fKBytesMBytesGBytes10^3bits10^6bits10^9bitsTransshutdown_control: shutdown of control connection requested. %s errno %d shutdown_control: error in shutdownshutdown_control: no response receivedWARNING, htonl conversion count of %d was larger than netperf_request entered send_request_n...contents before %d htonls: send_request_n...contents after %d htonls: send_request: about to send %u bytes from %p send_request: send call failuresend_response_n: contents of %u ints before %d htonl, send_response_n: contents after htonl about to send %u bytes from %p send_response_n: send call failureBytesSent: %d recv_request: received %d bytes of request. recv_request: error on recvrecv_request: remote requested shutdown of control recv_request: partial request received of %d bytes WARNING, htonl conversion count of %d was larger than netperf_response netperf: receive_response: no response received. errno %d counter %d recv_response: received a %d byte response recv_responserecv_response: partial response received: %d bytes UnknownRemoteSysnameUnknownRemoteReleaseUnknownRemoteMachineUnknownRemoteVersionhello world debug: %d netperf: get_sock_buffer: getsockopt %s: errno %d SO_SNDBUFSO_RCVBUFnetperf: get_sock_buffer: %s socket size determined to be %d sendreceivenetperf: set_sock_buffer: %s option: errno %d netperf: set_sock_buffer: %s of %d requested. getaddrinfo returned the following for host '%s' port '%s' family %s cannonical name: '%s' flags: %x family: %s: socktype: %s protocol %s addrlen %d (nil) sa_family: %s sadata: %d %.2x resolve_host called with host '%s' port '%s' family %s Sleeping on getaddrinfo EAI_AGAIN %s: could not resolve host '%s' port '%s' af %s getaddrinfo returned %d %s establish_control called with host '%s' port '%s' remfam %s local '%s' port '%s' locfam %s establish_control: unable to allocate control socketbound control socket to %s and %s successful connection to remote netserver at %s and %s establish_control: connect failed, errno %d %s trying next address combination establish_control: bind failed, errno %d %s trying next address combination establish control: are you sure there is a netserver listening on %s at port %s? establish_control could not establish the control connection from %s port %s address family %s to %s port %s address family %s identify_local: uname%-15s%-15s%-15s%-15s%-15sLocal Information Sysname Nodename Release Version Machine %s identify_remote: on remoteRemote Information Sysname Nodename Release Version Machine %sWARNING calc_throughput_internal_omni: unknown units %c calc_service_demand called: units_sent = %f elapsed_time = %f cpu_util = %f num cpu = %d calc_service_demand using: units_sent = %f elapsed_time = %f cpu_util = %f num cpu = %d calc_service_demand got: thruput = %f servdem = %f msec_sleep: selectHIST_new_n - histogram_struct malloc failedHIST_new_n - time_ones malloc failed: %4dUNIT_USEC TEN_USEC HUNDRED_USEC UNIT_MSEC TEN_MSEC HUNDRED_MSEC UNIT_SEC TEN_SEC >100_SECS: %d HIST_TOTAL: %d HIST_timestamp_start called with NULL histogram HIST_timestamp_start called with full time_ones HIST_timestamp_stop called with NULL histogram HIST_timestamp_stop called with empty time_ones consumer %d producer %d calculate_confidence: itr %d; time %f; res %f lcpu %f; rcpu %f lsdm %f; rsdm %f Conf_itvl %2d: results:%4.1f%% loc_cpu:%4.1f%% rem_cpu:%4.1f%% !!! WARNING !!! Desired confidence was not achieved within the specified iterations. !!! This implies that there was variability in the test environment that !!! must be investigated before going further. !!! Confidence intervals: Throughput : %4.3f%% !!! Local CPU util : %4.3f%% !!! Remote CPU util : %4.3f%% Attempting to parse address family from %s derived from %s 6inet4unspec0WARNING! %s not recognized as an address family, using AF_UNPSEC Are you sure netperf was configured for that address family? Attempting to parse socket type from %s derived from %s streamdgramxmitsendtransmitrecvreceivemaertsrrAttempting to parse protocol from %s derived from %s tcpudpsctpTCP_STREAM12865%s%s%smalloc() to store program name failed! malloc(%d) failed! A:a:b:B:CcdDf:F:H:hi:I:jk:K:l:L:n:NO:o:P:p:rSs:t:T:v:VW:w:46Sorry, Demo Mode not configured into this netperf. Please consider reconfiguring netperf with --enable-demo=yes and recompiling Only 95%% and 99%% confidence level is supported I don't know how to get dirty. Unable to malloc space for result brand Netperf version %s 2.5.0localhost::1Netperf does not understand %d as an address family Netperf could not resolve %s as a host name 0.0.0.0::0TCP_MAERTSTCP_RRTCP_CRRUDP_STREAMUDP_RRTCP_SENDFILETCP_CCTCP_MSSomniRRRrrRProgram name: %s Local send alignment: %d Local recv alignment: %d Remote send alignment: %d Remote recv alignment: %d Report local CPU %d Report remote CPU %d Verbosity: %d Debug: %d Port: %s Test name: %s Test bytes: %d Test time: %d Test trans: %d Host name: %s StreamDatagramSeqpacketUnknownTCPUDPSCTPIP DefaultUnknown Protocoltcpnetperf: get_tcp_info: getsockopt TCP_MAXSEG: errno %d complete_addrinfo using hostname %s port %s family %s type %s prot %s flags 0x%x Sleeping on getaddrinfo EAI_AGAIN complete_addrinfo: could not resolve '%s' port '%s' af %d getaddrinfo returned %d %s WARNING! Changed bogus getaddrinfo socket type %d to %d WARNING! Changed bogus getaddrinfo protocol %d to %d WARNING! getaddrinfo returned a socket type which did not match the requested type. Please contact your vendor for a fix to this bug in getaddrinfo() WARNING! getaddrinfo returned a protocol other than the requested protocol. Please contact your vendor for a fix to this bug in getaddrinfo() WARNING! getaddrinfo on this platform does not accept IPPROTO_SCTP! Please contact your vendor for a fix to this bug in getaddrinfo(). WARNING! getaddrinfo on this platform does not accept IPPROTO_DCCP! Please contact your vendor for a fix to this bug in getaddrinfo(). local_data_address not set, using local_host_name of '%s' local_data_address not set, using address family info 0.0.0.0::0what to put here?%uGiven Unexpected Address Family of %u UNKN FAMILYset_port_number Unexpected Address Family of %u set_sockaddr_family_addr_port Unexpected Address Family of %u get_sockaddr_family_addr_port family mismatch %d vs %d get_sockaddr_family_addr_port: Unexpected Address Family of %u netperf: create_data_socket: socket: errno %d fam %s type %s prot %s errmsg %s create_data_socket: socket %d obtained... netperf: create_data_socket: nodelay: errno %d netperf: create_data_socket: [TCP|SCTP]_NODELAY requested... %s: unable to set SO_KEEPALIVE on data socket: %s (errno %d) netperf: create_data_socket: SO_REUSEADDR failed %d netperf: create_data_socket: data socket bind failed errno %d port: %d netperf: create_data_socket: so_dontroute: errno %d we never expected to get here in get_address_address %s from %s (%s) port %u %s to %s (%s) port %u %s : +/-%.3f%% @ %2d%% conf. %s on result only : nodelay : copy avoidance : no control : spin intervalREQUEST/RESPONSE : first burst %d : cpu bind Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. %s/sec %7.2f %s %6d %6d %6d %-6.2f %7.2f %s Recv Send Send Utilization Service Demand Socket Socket Message Elapsed Send Recv Send Recv Size Size Size Time Throughput local remote local remote bytes bytes bytes secs. %-8.8s/s %% %c %% %c us/KB us/KB %6.3f %c %s %6d %6d %6d %-6.2f %7.2f %-6.2f %-6.2f %-6.3f %-6.3f %s Alignment Offset %-8.8s %-8.8s Sends %-8.8s Recvs Local Remote Local Remote Xfered Per Per Send Recv Send Recv Send (avg) Recv (avg) %5d %5d %5d %5d %6.4g %6.2f %6d %6.2f %6d Maximum Segment Size (bytes) %6d TCP STREAM TESTnetperf: send_tcp_stream: tcp stream data socketsend_tcp_stream: send_socket obtained... netperf: send_tcp_stream: requesting TCP stream test remote listen done. netperf: remote error %dnetperf: send_tcp_stream: data socket connect failednetperf: data send errorlen was %d about to spin suspend netperf: cannot shutdown tcp stream socketremote reporting results for %.2f seconds BytesRecv Send Send Utilization Service Demand Socket Socket Message Elapsed Recv Send Recv Send Size Size Size Time Throughput local remote local remote bytes bytes bytes secs. %-8.8s/s %% %c %% %c us/KB us/KB Alignment Offset %-8.8s %-8.8s Recvs %-8.8s Sends Local Remote Local Remote Xfered Per Per Recv Send Recv Send Recv (avg) Send (avg) %5d %5d %5d %5d %6.4g %6.2f %6d %6.2f %6d TCP MAERTS TESTnetperf: send_tcp_maerts: tcp stream data socketsend_tcp_maerts: recv_socket obtained... netperf: send_tcp_maerts: requesting TCP maerts test netperf: send_tcp_maerts: data socket connect failednetperf: send_tcp_maerts: test must be timed send_tcp_maerts: data recv errornetperf: cannot shutdown tcp maerts socketremote results obtained Maximum Segment Size (bytes) %d %s TCP MSS TESTnetperf: send_tcp_mss: requesting TCP stream test netperf: send_tcp_mss: data socket connect failedTCP SENDFILE TESTnetperf: sendfile_tcp_stream: tcp stream data socketsendfile_tcp_stream: send_socket obtained... netperf: data send error: sendfilelen was %d send_size was %d netserver: recv_tcp_stream: entered... recv_tcp_stream: setting the response type... recv_tcp_stream: the response type is set... recv_tcp_stream: requested alignment of %d recv_tcp_stream: receive alignment and offset set... recv_tcp_stream: got %g bytes recv_tcp_stream: got %d recvs recv_tcp_stream: test complete, sending results. bytes_received %g receive_calls %d len %d netserver: recv_tcp_maerts: entered... recv_tcp_maerts: setting the response type... recv_tcp_maerts: the response type is set... recv_tcp_maerts: requested alignment of %d recv_tcp_maerts: grabbing a socket... recv_tcp_maerts: receive alignment and offset set... recv_tcp_maerts: got %g bytes recv_tcp_maerts: got %d sends recv_tcp_maerts: test complete, sending results. bytes_sent %g send_calls %d Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec Local /Remote Socket Size Request Resp. Elapsed Send Recv Size Size Time Throughput bytes Bytes bytes bytes secs. %s/sec %-6d %-6d %-6d %-6d %-6.2f %7.2f %s %-6d %-6d Local /Remote Socket Size Request Resp. Elapsed Trans. CPU CPU S.dem S.dem Send Recv Size Size Time Rate local remote local remote bytes bytes bytes bytes secs. per sec %% %c %% %c us/Tr us/Tr Local /Remote Socket Size Request Resp. Elapsed Tput CPU CPU S.dem S.dem Send Recv Size Size Time %-8.8s local remote local remote bytes bytes bytes bytes secs. per sec %% %c %% %c us/Tr us/Tr Local /Remote Socket Size Request Resp. Elapsed Latency CPU CPU S.dem S.dem Send Recv Size Size Time usecs local remote local remote bytes bytes bytes bytes secs. per tran %% %c %% %c us/Tr us/Tr %-6d %-6d %-6d %-6d %-6.2f %-6.2f %-6.2f %-6.2f %-6.3f %-6.3f %s Alignment Offset RoundTrip Trans Throughput Local Remote Local Remote Latency Rate %-8.8s/s Send Recv Send Recv usec/Tran per sec Outbound Inbound %5d %5d %5d %5d %-6.3f %-6.3f %-6.3f %-6.3f TCP REQUEST/RESPONSE TESTnetperf: send_tcp_rr: tcp stream data socketsend_tcp_rr: send_socket obtained... netperf: send_tcp_rr: requesting TCP rr test netperf: data socket connect failedinjecting, req_outstndng %d req_cwnd %d burst %d send_tcp_rr: initial burst data send errorsend_tcp_rr: data send errorsend_tcp_rr: data recv errorincr req_cwnd to %d first_burst %d reqs_outstndng %d Transaction %d completed Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # %s/sec %7.2f %6d %6d %-7.2f %7d %6d %7.2f %6d %-7.2f %7d %7.2f Socket Message Elapsed Messages CPU Service Size Size Time Okay Errors Throughput Util Demand bytes bytes secs # # %s/sec %% %c%c us/KB %6.2f %c %6d %6d %-7.2f %7d %6d %7.1f %-6.2f %-6.3f %6d %-7.2f %7d %7.1f %-6.2f %-6.3f UDP UNIDIRECTIONAL SEND TESTudp_send: data socketsend_udp_stream: remote data connection done. send_udp_stream: error on remotesend_udp_stream: data socket connect failedsend_udp_stream: connected data socket. Sorry, UDP_STREAM tests must be timed. udp_send: data send errorsend_udp_stream: remote results obtained netserver: recv_udp_stream: entered... recv_udp_stream: setting the response type... recv_udp_stream: the response type is set... recv_udp_stream: requested alignment of %d recv_udp_stream: receive alignment and offset set... recv_udp_stream: grabbing a socket... recv_udp_stream: about to enter inner sanctum. recv_udp_stream: connected data socket recv_udp_stream: got %d messages. recv_udp_stream: test ended in %f seconds. recv_udp_stream: got %d bytes recv_udp_stream: test complete, sending results. %-6d %-6d %-6d %-6d %-6.2f %-6.2f %-6.2f %-6.2f %-6.3f %-6.3f %s UDP REQUEST/RESPONSE TESTnetperf: send_udp_rr: udp rr data socketsend_udp_rr: send_socket obtained... netperf: send_udp_rr: requesting UDP r/r test send_udp_rr: initial burst data send errorsend_udp_rr: data send errorsend_udp_rr: data recv errornetserver: recv_udp_rr: entered... recv_udp_rr: setting the response type... recv_udp_rr: the response type is set... recv_udp_rr: requested recv alignment of %d offset %d recv_udp_rr: requested send alignment of %d offset %d recv_udp_rr: receive alignment and offset set... recv_udp_rr: grabbing a socket... recv port number %d recv_udp_rr: Transaction %d complete. recv_udp_rr: got %d transactions recv_udp_rr: test complete, sending results. netserver: recv_tcp_rr: entered... recv_tcp_rr: setting the response type... recv_tcp_rr: the response type is set... recv_tcp_rr: requested recv alignment of %d offset %d recv_tcp_rr: requested send alignment of %d offset %d recv_tcp_rr: grabbing a socket... recv_tcp_rr: accept completes on the data connection. zero is my hero yo5 yo6 recv_tcp_rr: got %d transactions recv_tcp_rr: test complete, sending results. %g There %s %d local %s areiscpuscpu There %s %d remote %s %-6d %-6d %-6d %-6d %-6.2f %7.2f Local /Remote Socket Size Request Resp. Elapsed Trans. CPU CPU S.dem S.dem Send Recv Size Size Time Rate local remote local remote bytes bytes bytes bytes secs. per sec %% %% us/Tr us/Tr %6.3f %-6d %-6d %-6d %-6d %-6.2f %-6.2f %-6.2f %-6.2f %-6.3f %-6.3f Alignment Offset Local Remote Local Remote Send Recv Send Recv %5d %5d %5d %5d TCP Connect/Request/Response TESTsend_tcp_conn_rr: send_socket obtained... netperf: send_tcp_conn_rr: requesting TCP crr test remote port is %u port %d netperf: send_tcp_conn_rr: tcp stream data socket attempted to connect on socket %d to port %d from port %d send_tcp_conn_rr: data send errorsend_tcp_conn_rr: data recv errorTransaction %d completed on local port %d WARNING WARNING WARNING WARNING WARNING WARNING WARNING! Local CPU usage numbers based on process information only! DANGER DANGER DANGER DANGER DANGER DANGER DANGER! Remote CPU usage numbers based on process information only! netserver: recv_tcp_conn_rr: entered... recv_tcp_conn_rr: setting the response type... recv_tcp_conn_rr: the response type is set... malloc(%d) failed! recv_tcp_conn_rr: requested recv alignment of %d offset %d recv_tcp_conn_rr: requested send alignment of %d offset %d recv_tcp_conn_rr: receive alignment and offset set... recv_tcp_conn_rr: grabbing a socket... could not create data socket could not listen could not getsockname telling the remote to call me at %d recv_tcp_conn_rr: accept: errno = %d recv_tcp_conn_rr: accepted data connection. recv_tcp_conn_rr: Transaction %d complete recv_tcp_conn_rr: got %d transactions recv_tcp_conn_rr: test complete, sending results. TCP Connect/Close TESTsend_tcp_cc: send_socket obtained... netperf: send_tcp_cc: requesting TCP crr test remote port is %d netperf: send_tcp_cc: tcp stream data socket from port %u Transaction %d completed on local port %u send_tcp_cc: data recv errornetserver: recv_tcp_cc: entered... recv_tcp_cc: setting the response type... recv_tcp_cc: the response type is set... recv_tcp_cc: requested recv alignment of %d offset %d recv_tcp_cc: requested send alignment of %d offset %d recv_tcp_cc: receive alignment and offset set... recv_tcp_cc: grabbing a socket... could not geetsockname recv_tcp_cc: accept: errno = %d recv_tcp_cc: accepted data connection. recv_tcp_cc: Transaction %d complete recv_tcp_cc: got %d transactions recv_tcp_cc: test complete, sending results. %s called with the following argument vector scan_sockets_args%s 0UDP_STREAMb:CDnNhH:L:m:M:p:P:r:R:s:S:T:Vw:W:z46WARNING: TCP_CORK not available on this platform! Local send copy avoidance not available. Local recv copy avoidance not available. STREAMSENDFILEdiscardRRechoMAERTSchargenNo default port known for the %s test, please set one yourself /dev/urandomrb%8.8x-%4.4x-%4.4x-%2.2x%2.2x-%2.2x %suuid string too small%s[%d]: idle %llu user %llu kernel %llu interrupt %llu cpu_util_init: kstat_open: errno %d %s cpusysMapping CPU instance %d to entry %d Sorry, this system has more CPUs (%d) than netperf can handle (%d). Please alter MAXCPUS in netlib.h and recompile. WARNING! WARNING! WARNING! WARNING! %s found an unexpected %s statistic %.16s %s is ignoring statistic %.16s cpu_nsec_idlecpu_nsec_usercpu_nsec_kernelcpu_nsec_intrFound a cpu_nsec_intr but it doesn't do what we want nsecget_cpu_countersget_cpu_counters could not find one or more of the expected counters! get_cpu_counters: kstat_read failed or chain id changed %d %s get_cpu_counters: kstat_lookup failed for module 'cpu' number %d instance %d name 'sys' and KSTAT_TYPE_NAMED: errno %d %s intrstattimeget_cpu_counters: kstat_lookup failed for module 'cpu' %d instance %d class 'intrstat' and KSTAT_TYPE_NAMED: errno %d %s delta_cpu_counterstotal_cpu_nsec %llu WARNING! WARNING! WARNING! WARNING! WARNING! calc_cpu_util_internal: more interrupt time than others combined! so CPU util cannot be estimated delta[%d].interrupt %llu delta[%d].idle %llu delta[%d].user %llu delta[%d].kernel %llu fraction_idle %llu interrupt_idle %llu fraction_user %llu interrupt_user %llu fraction_kernel %llu interrupt_kernel %llu corrected_cpu_counters fraction_idle %lu fraction_user %lu fraction_kernel %lu fraction_interrupt %lu lib_local_per_cpu_util[%d] %g cf %f socketmallocSIOCIFCONFEgressByAddrnoindexlo0callocUnknown AFwritereadLastHop AFNoAlphaUnavailableNot Implementedclass,.subsystem-vendor-idsubsystem-idvendor-iddevice-id/kstat_opencpu_infokstat_lookupkstat_readbrandclock_MHzCPU Not Found,sysinfoN/ANjPzPPPPPPPPP QQ*Q:QJQZQjQzQQQQQQQQQ RR*R:RJRZRjRzRRRRRRRRR SS*S:SJSZSjSzSSSSSSSSS TT*T:TJTZTjTzTTTTTTTTT UU*U:UJUZUjUzUUUUUUUUU VV*V:VJVZVjVzVVVVVVVVV WW*W:WJWZWjWzWWWW/G\s  0  ogolKoL|Lo`oLW@(#)netserver.c (c) Copyright 1993-2011 Hewlett-Packard Co. Version 2.5.0?$$$$@(#)netlib.c (c) Copyright 1993-2011 Hewlett-Packard Company. Version 2.5.0 Usage: netserver [options] Options: -h Display this text -D Do not daemonize -d Increase debugging output -f Do not spawn chilren for each test, run serially -L name,family Use name to pick listen address and family for family -N No debugging output, even if netperf asks -p portnum Listen for connect requests on portnum. -4 Do IPv4 -6 Do IPv6 -v verbosity Specify the verbosity level -V Display version information and exit Usage: netperf [global options] -- [test options] Global options: -a send,recv Set the local send,recv buffer alignment -A send,recv Set the remote send,recv buffer alignment -B brandstr Specify a string to be emitted with brief output -c [cpu_rate] Report local CPU usage -C [cpu_rate] Report remote CPU usage -d Increase debugging output -D [secs,units] * Display interim results at least every secs seconds using units as the initial guess for units per second -f G|M|K|g|m|k Set the output units -F fill_file Pre-fill buffers with data from fill_file -h Display this text -H name|ip,fam * Specify the target machine and/or local ip and family -i max,min Specify the max and min number of iterations (15,1) -I lvl[,intvl] Specify confidence level (95 or 99) (99) and confidence interval in percentage (10) -j Keep additional timing statistics -l testlen Specify test duration (>0 secs) (<0 bytes|trans) -L name|ip,fam * Specify the local ip|name and address family -o send,recv Set the local send,recv buffer offsets -O send,recv Set the remote send,recv buffer offset -n numcpu Set the number of processors for CPU util -N Establish no control connection, do 'send' side only -p port,lport* Specify netserver port number and/or local port -P 0|1 Don't/Do display test headers -r Allow confidence to be hit on result only -s seconds Wait seconds between test setup and test start -S Set SO_KEEPALIVE on the data connection -t testname Specify test to perform -T lcpu,rcpu Request netperf/netserver be bound to local/remote cpu -v verbosity Specify the verbosity level -W send,recv Set the number of send,recv buffers -v level Set the verbosity level (default 1, min 0) -V Display the netperf version and exit For those options taking two parms, at least one must be specified; specifying one value without a comma will set both parms to that value, specifying a value with a leading comma will set just the second parm, a value with a trailing comma will set just the first. To set each parm to unique values, specify both and separate them with a comma. * For these options taking two parms, specifying one value with no comma will only set the first parms and will leave the second at the default value. To set the second value it must be preceded with a comma or be a comma-separated pair. This is to retain previous netperf behaviour. @(#)netsh.c (c) Copyright 1993-2011 Hewlett-Packard Company. Version 2.5.0.Ahgh Usage: netperf [global options] -- [test options] TCP/UDP BSD Sockets Test Options: -b number Send number requests at start of _RR tests -C Set TCP_CORK when available -D [L][,R] Set TCP_NODELAY locally and/or remotely (TCP_*) -h Display this text -H name,fam Use name (or IP) and family as target of data connection -L name,fam Use name (or IP) and family as source of data connection -m bytes Set the send size (TCP_STREAM, UDP_STREAM) -M bytes Set the recv size (TCP_STREAM, UDP_STREAM) -n Use the connected socket for UDP locally -N Use the connected socket for UDP remotely -p min[,max] Set the min/max port numbers for TCP_CRR, TCP_TRR -P local[,remote] Set the local/remote port for the data socket -r req,[rsp] Set request/response sizes (TCP_RR, UDP_RR) -s send[,recv] Set local socket send/recv buffer sizes -S send[,recv] Set remote socket send/recv buffer sizes -4 Use AF_INET (eg IPv4) on both ends of the data conn -6 Use AF_INET6 (eg IPv6) on both ends of the data conn For those options taking two parms, at least one must be specified; specifying one value without a comma will set both parms to that value, specifying a value with a leading comma will set just the second parm, a value with a trailing comma will set just the first. To set each parm to unique values, specify both and separate them with a comma. @(#)nettest_bsd.c (c) Copyright 1993-2011 Hewlett-Packard Co. Version 2.5.0@(#)nettest_sctp.c (c) Copyright 2005-2007 Hewlett-Packard Co. Version 2.4.3@(#)nettest_sdp.c (c) Copyright 2007 Hewlett-Packard Co. Version 2.4.4@(#)netcpu_kstat10.c (c) Copyright 2005-2011, Hewlett-Packard Company Version 2.5.00lK|LLL TP W   LNOgg   O=OPVO amOxg X( Y7 q xgmO$s( s s ggxgm8PU xgmQh( @t * : Xy lgd_h_l_gg__xgmD_hgxgmO xgmO !xgmO /xgmf >xgmQf LxgmO [f v0   P  xhmfP fQ 0 +0& B`L X  l   h   x hmf0fxgmO xgmO   p gg$g4 gD x mg O`0 gt@  xgmg gxgmO  L Q$Vp O*e BPIVP _0 s~P ^ fPPW"  QT Rw  ^.dU5( CTGt_P1 Xn e  T2 Qb4UhPTeLT !{ );8 IPuQ_`# TP TdV$QtY  g  N ( = IM T4dtUsO s 0 @YI `x RЀ*  e V #  + vY 5 Pdj G QU R\ o I tW  U P OJ T  ^K     P= QQ  d hr Ly m 3 0, tQ P  ,     Qo  `  0] ) Q1  B Pc Qn e  $Rx  T  ) $W S , @ n TP    xP* $T. dP8 | F p V 8 f L w $U  @_ L g W V $ X_    Q V! X * V1 8 k K l U E ] Uc o Qv Ш: PX{ pY kTT p> 0 p  x  eL 0 @c `@ U^-U4V?OHPNЃ cpPC ! zP`r S <`_\   P W*PB tV Np_WP^hP} t2 S| `= OdWtA t \_&  ) @O!9S>HWU<\ydOp` H (M w R<uy D ^S* VTQx- dS8P  +dR0:`| ` TPl= vp UHPS`r% d М ^DS$  ! 8XP5P B`PWP{RVP DP @b Q0' QVp 'p 7^N `VLPY  U  fh p m < @L !  U|_ 4   (Q`  &84fTFWPo~z |pa  `@i.  0 0i  UPN @J 1S8A4RHPq  0w  0 `  ~ QtRp TS@ TT*^9P@UFЫ2 SJ i @PTR@ TV0Q dT  Ry JT( 6x_tSGt WQi@yX pj' Q(_P4SLPQTW  [  0"^8% L0 \ jSpPP8_ tTP_V0І  `  DQY DV)L_6] x4QEPLxq ^# ol  NO@!    @H_y0_P Э H![ p` DW!Q,PC P@uY Z|gRnP d} $ P6 dQ8 netservercrti.scrt1.ocrt1.s__get_exit_frame_monitor_ptr__do_exit_code_ptrfsr.strap_tablevalues-Xa.cDdata.dataBbss.bssDrodata.rodatanetserver.c_xmknodinit_netserver_globalscheck_if_inetdnetlib.c_unameusec_per_itvlmeasuring_cpunetsh.cconvert_to_uppernettest_bsd.cget_tcp_infoget_port_numberextract_inet_address_and_portget_address_addressconfidence_iterationintvl_one_ptrintvl_two_ptrtemp_intvl_ptrlocal_cpu_methodremote_cpu_methodclient_port_maxclient_port_minintvl_oneintvl_twonettest_dlpi.cnettest_unix.cnettest_xti.cnettest_sctp.cnettest_sdp.cnettest_omni.cnet_uuid.cget_system_timeget_random_infotrue_randomget_current_timeget_ieee_node_identifierformat_uuid_v1netcpu_kstat10.cprint_cpu_time_counterskcprint_unexpected_statistic_warningget_cpu_countersget_interrupt_countersget_cpu_time_countersending_cpu_countersstarting_cpu_countersdelta_cpu_counterscorrected_cpu_counterskcidnetrt_rtmget.cnetdrv_solaris.cnetslot_solaris.cset_interface_matchparse_binding_namefound_vendorfound_devicefound_subvendorfound_subdevicecheck_nodenetsys_solaris.cfind_cpu_model_freqfind_system_model_sysinfofind_system_modelnetsec_none.ccrtn.s_END__START_establish_control_internallsr_sizelistenkstat_closeget_sockaddr_family_addr_port__longdouble_usedalloc_sendfile_buf_ringatexitfwriteremote_machineset_sock_bufferget_cpu_methodoutput_rowresult_brandkeep_statisticsmulticast_ttlmeasured_sum_result_get_exit_frame_monitorunknownprogrammsec_sleepgettimeofdayfprintfsend_tcp_cclocal_recv_offsetstrtodinterval_watepowrsp_sizelibmainconfidence_iterationsfind_egress_interface_by_linkrem_tcpcorkget_sock_bufferstrtokget_uuid_stringprint_netserver_usagestrtolmeasured_var_resultsqrtlss_size_endremote_interval_burstlss_sizecatcherremote_send_alignlocal_sysnamemeasured_var_local_service_demandprocessor_bindprint_sockets_usagebreak_args_explicit_sep__xtoldump_addrinfomkstemp64ioctlchmodnsec_enabled_to_strset_defaultscalc_service_demand_fmtset_sockaddr_family_addr_portcalculate_confidencenetlib_initnst_to_hstrem_clean_countgetprotobynamesuppress_debugestablish_controlcalibrate_remote_cpuget_remote_system_infounlink_empty_debug_filescan_cmd_linestrncpylocal_cpu_usagerecv_tcp_rrlsr_size_enduuid_create__ctypeinet_ftosclose_listensget_result_confidsetsidlib_local_cpu_utilcalc_service_demandsmbios_open__fsr_init_valuesendfilev64measured_sum_remote_service_demandnetserver_idfreeaddrinfoserver_controlnetsh_idlisten_portconfidence_levelmeasured_square_sum_remote_cpuremote_data_addresscomplete_addrinfosrequest_array_etextscan_netserver_argsscan_sockets_argsHIST_purgestrduprsr_sizeverbositylib_remote_maxratelib_num_loc_cpusremote_data_familyformat_cpu_methodHIST_reportset_server_sockfopen64remote_cpu_usagemeasured_mean_remote_cpudisplay_confidencetest_namemeasured_failssend_udp_streamcomplete_addrinfodi_prop_intssigactionlib_local_maxrateget_idsend_request_n_PROCEDURE_LINKAGE_TABLE_cpu_util_initmeasured_square_sum_local_cpu__fpstartlocal_releasesend_response_nrecv_tcp_maertsnetperf_responsestrcasecmpHIST_newnf_to_af_GLOBAL_OFFSET_TABLE__edatasmbios_info_commondi_prop_nextwherefirst_burst_sizeremote_data_portmeasured_mean_remote_timedi_minor_namerss_sizecallocoptindaccept_connectionsrecv_sizesum_rowbzeroloc_nodelaymemsetidentify_local__fsrhst_to_strbind_to_specific_processorcreate_data_socketwant_daemonizewait_time_secsnettest_idinit_statset_fdsetrecv_udp_streamrecvfromremote_send_offsetstrchrkstat_open_environ_exitallocate_buffer_ringmeasured_sum_local_cpumeasured_var_remote_service_demandcalibrate_local_cpurewindresponse_arrayHIST_search_bucketFileNamersr_size_reqlocal_host_namelib_use_idleparse_directiondi_prop_namemeasured_sum_local_timestop_itimerreq_sizestat64fill_filestart_timercalc_thruput_omnifreadcalc_service_demand_internaldaemon_parentnsec_type_to_strremote_sysnamenetlib_get_page_sizerss_size_reqHIST_timestamp_stop_addoptarglib_num_rem_cpuslocal_data_portnetperf_usage1smbios_closenetperf_usage2listen_listcpu_start_internaltest_transremote_versionHIST_clearhtondchdirtimes_upinet_ptosset_hostname_and_portlocal_send_offsetsigaddsetset_nonblockrand32htonllibfmtrecv_tcp_conn_rrforkdemo_moderetrieve_confident_valuesmeasured_mean_local_cpucpu_startnetperf_requestlocal_address_familyhtonslocal_proc_affinitylocal_send_alignHIST_timestamp_startrecv_response_timedremote_recv_offsetsetitimeriteration_minmeasured_square_sum_resultsend_requestmeasured_mean_resultmeasured_mean_remote_service_demandstrcmpdi_binding_namemeasured_sum_local_service_demanddi_initprint_top_test_headermeasured_var_local_timedump_requestmeasured_mean_local_timememcmplocal_test_portset_port_numberresult_confidence_onlycpu_stop_internalnetlib_controlinet_ntonrss_size_endrem_rcvavoidinet_ntopkstat_lookupsigemptysetrecvremote_interval_usecsfree__environ_lockgetoptinstall_signal_catchersopen_debug_filenetperf_daemondump_responsesprintfperrorshutdownformat_numberremote_send_widthparse_protocolrsr_size_endsend_tcp_rrremote_cpu_ratetime1get_num_cpusnetlib_idtime2nettest_sctpselectcalc_thruput_interval_omnicpu_util_terminateloc_cpu_ratelib_cpu_maplib_local_peak_cpu_idget_local_system_inforecv_response_timed_nnettest_sdpstrcpygai_strerrorsrand_nunamerouting_allowedformat_unitsparse_socket_typedi_prop_typerecv_responseerrnoHIST_timestampconvertmemcpybreak_argsiteration_maxloc_rcvavoidatofHIST_get_stats__assertatoirecv_request_ncpu_stopgetaddrinfonetperf_versiondemo_intervalconnectget_loc_cpu_confidsnpuidtoupperloc_tcpcorkkeep_histogramrecv_tcp_cc__iobrem_nodelaystop_timerlib_local_per_cpu_util__1cG__CrunMdo_exit_code6F_v_netlib_init_cpu_mapdi_minor_nextaf_to_nfconvert_timespectest_timerecv_response_nprotocol_to_strtest_bytesHIST_get_percentilesendfile_tcp_streamfind_driver_infosendtolocal_connectedshutdown_controlprint_headersHIST_new_nsend_tcp_conn_rrlocal_machinenetcpu_kstat10_idlocal_recv_alignmeasured_sum_remote_cpustart_itimersetup_listensparse_address_familylocal_cpu_ratespawn_childfind_interface_slotfind_security_infosend_udp_rrloc_dirty_countgethrtimemeasured_square_sum_remote_service_demandstrlencmd_filestrstrmeasured_square_sum_local_service_demandlib_remote_peak_cpu_utilntohd_lib_versiondelta_microfind_interface_idsrem_dirty_countidentify_remotespawn_on_acceptsend_tcp_streamntohlsend_tcp_maertsgetsockoptcommand_lineshell_num_cpusgetpidntohscalc_thruputcalc_thruput_intervalfind_egress_interface_by_addrremote_proc_affinitysignalnot_inetdloc_sndavoid__udiv64get_rem_cpu_confidbreak_args_explicitfcntllib_remote_cpu_utillib_elapsedgetsocknamerecv_udp_rrsend_responseremote_connectedloc_clean_countlocal_data_familyunits_this_ticklib_local_peak_cpu_utilrem_cpu_rateaccept_connectionsetsockoptremote_recv_widthunlinksysconfcontrol_familylocal_data_addressdi_finidump_globalstest_len_tickscpu_binding_requestedprint_netperf_usagerecv_tcp_streamlocal_versionalarmmeasured_square_sum_local_timemeasured_mean_local_service_demanddemo_unitsinterval_countsendwant_keepalivesend_sizeif_indextonametzaccess_bufferHIST_addhst_to_nstkstat_readlsr_size_reqcreate_listensfflushrandom_ip_addressfind_system_inforemote_recv_align_DYNAMIC___Argvcalc_cpu_util_internalrecv_requestmeasured_local_resultslss_size_reqsnprintfcalibrate_idle_ratecalc_cpu_utilremote_releasedi_walk_nodeno_controlmeasured_var_local_cpuresolve_hostinet_ttosrem_sndavoidmallocmeasured_var_remote_cpusend_tcp_mssprocess_requestslib_remote_peak_cpu_idfind_egress_interfacefilenousernameanotate anotate0 ,(WNWYXOOanotate anotate tttttttttt|{}{_pptx| ̏$0܏<anotate ,<`L4   $X(,-0,48<@(DHLTP\TxX\`dh|lptx|`anotate  5  -,  $h (h ,H 0 4 dLL!!!!!L!!L!.0/00$-0-0-0.0(/0(/UPSRSSMSNSNShPS4QS4Q_````^`@_`@_```4``4`vxxxxHtxuxuxvxhwxhwԗ QM(ttdCSsS<WD[p_cgk o<sw{ԹPanotate anotate anotate anotate @(#)string.h 1.27 07/01/14 SMI@(#)string_iso.h 1.5 04/06/18 SMI@(#)feature_tests.h 1.25 07/02/02 SMI@(#)ccompile.h 1.2 04/11/08 SMI@(#)isa_defs.h 1.29 08/06/06 SMI@(#)strings.h 1.3 96/03/12 SMI@(#)types.h 1.86 07/09/20 SMI@(#)machtypes.h 1.11 04/09/28 SMI@(#)machtypes.h 1.2 04/09/28 SMI@(#)int_types.h 1.10 04/09/28 SMI@(#)select.h 1.19 04/01/28 SMI@(#)time_impl.h 1.11 05/05/19 SMI@(#)time.h 2.77 09/06/02 SMI@(#)time.h 1.45 08/01/09 SMI@(#)time_iso.h 1.4 04/09/07 SMI@(#)limits.h 1.59 04/08/24 SMI@(#)limits_iso.h 1.2 03/12/04 SMI@(#)int_limits.h 1.9 04/09/28 SMI@(#)ipc.h 1.23 03/02/05 SMI@(#)ioctl.h 1.9 92/07/14 SMI@(#)socket.h 1.78 08/01/18 SMI@(#)uio.h 1.34 09/06/15 SMI@(#)socket_impl.h 1.1 05/08/02 SMI@(#)un.h 1.11 02/10/02 SMI@(#)if_dl.h 1.10 03/05/21 SMI@(#)netconfig.h 1.24 04/02/27 SMI@(#)in.h 1.55 09/05/27 SMI@(#)stream.h 1.115 08/07/22 SMI@(#)vnode.h 1.133 09/07/17 SMI@(#)t_lock.h 1.45 98/02/01 SMI@(#)machlock.h 1.25 04/07/19 SMI@(#)param.h 1.82 06/01/30 SMI@(#)unistd.h 1.43 06/03/10 SMI@(#)mutex.h 1.21 07/04/04 SMI@(#)rwlock.h 1.9 98/02/18 SMI@(#)semaphore.h 1.5 98/02/01 SMI@(#)condvar.h 1.14 04/10/21 SMI@(#)rwstlock.h 1.4 04/11/09 SMI@(#)ksynch.h 1.6 97/10/22 SMI@(#)cred.h 1.27 06/05/03 SMI@(#)resource.h 1.37 07/02/07 SMI@(#)seg_enum.h 1.9 09/07/02 SMI@(#)kstat.h 1.22 07/02/02 SMI@(#)kmem.h 1.38 09/05/07 SMI@(#)vmem.h 1.12 05/06/27 SMI@(#)poll.h 1.28 98/11/23 SMI@(#)strmdep.h 1.10 98/01/06 SMI@(#)model.h 1.24 04/09/28 SMI@(#)strft.h 1.2 00/03/17 SMI@(#)byteorder.h 1.18 04/09/28 SMI@(#)stat.h 1.11 04/09/28 SMI@(#)stat_impl.h 1.4 03/12/04 SMI@(#)netdb.h 1.30 03/12/04 SMI@(#)unistd.h 1.76 06/03/10 SMI@(#)stdlib.h 1.51 04/06/30 SMI@(#)stdlib_iso.h 1.9 04/09/28 SMI@(#)stdlib_c99.h 1.2 04/03/29 SMI@(#)errno.h 1.17 03/01/03 SMI@(#)errno.h 1.20 00/01/12 SMI@(#)signal.h 1.43 04/09/28 SMI@(#)signal_iso.h 1.1 99/08/09 SMI@(#)signal_iso.h 1.6 03/05/02 SMI@(#)signal.h 1.66 04/09/28 SMI@(#)siginfo.h 1.59 04/07/15 SMI@(#)machsig.h 1.11 03/09/26 SMI@(#)faultcode.h 1.16 09/07/02 SMI@(#)procset.h 1.25 04/07/16 SMI@(#)stdio.h 1.84 04/09/28 SMI@(#)stdio_iso.h 1.8 05/08/16 SMI@(#)va_list.h 1.15 04/11/19 SMI@(#)stdio_tag.h 1.4 04/09/28 SMI@(#)stdio_impl.h 1.15 07/03/05 SMI@(#)stdio_c99.h 1.2 04/03/29 SMI@(#)fcntl.h 1.17 06/03/10 SMI@(#)fcntl.h 1.52 07/03/05 SMI@(#)inttypes.h 1.4 04/04/29 SMI@(#)inttypes.h 1.3 03/12/04 SMI@(#)int_const.h 1.5 04/09/28 SMI@(#)int_fmtio.h 1.6 04/09/28 SMI@(#)stdint.h 1.1 03/12/04 SMIacomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13@(#)limits.h 1.59 04/08/24 SMI@(#)feature_tests.h 1.25 07/02/02 SMI@(#)ccompile.h 1.2 04/11/08 SMI@(#)isa_defs.h 1.29 08/06/06 SMI@(#)limits_iso.h 1.2 03/12/04 SMI@(#)int_limits.h 1.9 04/09/28 SMI@(#)signal.h 1.43 04/09/28 SMI@(#)types.h 1.86 07/09/20 SMI@(#)machtypes.h 1.11 04/09/28 SMI@(#)machtypes.h 1.2 04/09/28 SMI@(#)int_types.h 1.10 04/09/28 SMI@(#)select.h 1.19 04/01/28 SMI@(#)time_impl.h 1.11 05/05/19 SMI@(#)time.h 2.77 09/06/02 SMI@(#)time.h 1.45 08/01/09 SMI@(#)time_iso.h 1.4 04/09/07 SMI@(#)signal_iso.h 1.1 99/08/09 SMI@(#)signal_iso.h 1.6 03/05/02 SMI@(#)unistd.h 1.43 06/03/10 SMI@(#)signal.h 1.66 04/09/28 SMI@(#)siginfo.h 1.59 04/07/15 SMI@(#)machsig.h 1.11 03/09/26 SMI@(#)faultcode.h 1.16 09/07/02 SMI@(#)procset.h 1.25 04/07/16 SMI@(#)fcntl.h 1.17 06/03/10 SMI@(#)fcntl.h 1.52 07/03/05 SMI@(#)stdio.h 1.84 04/09/28 SMI@(#)stdio_iso.h 1.8 05/08/16 SMI@(#)va_list.h 1.15 04/11/19 SMI@(#)stdio_tag.h 1.4 04/09/28 SMI@(#)stdio_impl.h 1.15 07/03/05 SMI@(#)stdio_c99.h 1.2 04/03/29 SMI@(#)stdlib.h 1.51 04/06/30 SMI@(#)stdlib_iso.h 1.9 04/09/28 SMI@(#)stdlib_c99.h 1.2 04/03/29 SMI@(#)math.h 2.24 04/10/23 SMI@(#)math_iso.h 1.9 04/10/23 SMI@(#)math_c99.h 1.9 04/11/01 SMI@(#)floatingpoint.h 2.9 04/10/23 SMI@(#)ieeefp.h 2.12 04/10/23 SMI@(#)string.h 1.27 07/01/14 SMI@(#)string_iso.h 1.5 04/06/18 SMI@(#)assert.h 1.10 04/05/18 SMI@(#)unistd.h 1.76 06/03/10 SMI@(#)stat.h 1.11 04/09/28 SMI@(#)stat_impl.h 1.4 03/12/04 SMI@(#)times.h 1.10 97/08/12 SMI@(#)socket.h 1.78 08/01/18 SMI@(#)uio.h 1.34 09/06/15 SMI@(#)socket_impl.h 1.1 05/08/02 SMI@(#)un.h 1.11 02/10/02 SMI@(#)if_dl.h 1.10 03/05/21 SMI@(#)netconfig.h 1.24 04/02/27 SMI@(#)in.h 1.55 09/05/27 SMI@(#)stream.h 1.115 08/07/22 SMI@(#)vnode.h 1.133 09/07/17 SMI@(#)t_lock.h 1.45 98/02/01 SMI@(#)machlock.h 1.25 04/07/19 SMI@(#)param.h 1.82 06/01/30 SMI@(#)mutex.h 1.21 07/04/04 SMI@(#)rwlock.h 1.9 98/02/18 SMI@(#)semaphore.h 1.5 98/02/01 SMI@(#)condvar.h 1.14 04/10/21 SMI@(#)rwstlock.h 1.4 04/11/09 SMI@(#)ksynch.h 1.6 97/10/22 SMI@(#)cred.h 1.27 06/05/03 SMI@(#)resource.h 1.37 07/02/07 SMI@(#)seg_enum.h 1.9 09/07/02 SMI@(#)kstat.h 1.22 07/02/02 SMI@(#)kmem.h 1.38 09/05/07 SMI@(#)vmem.h 1.12 05/06/27 SMI@(#)poll.h 1.28 98/11/23 SMI@(#)strmdep.h 1.10 98/01/06 SMI@(#)model.h 1.24 04/09/28 SMI@(#)strft.h 1.2 00/03/17 SMI@(#)byteorder.h 1.18 04/09/28 SMI@(#)inet.h 1.21 08/01/04 SMI@(#)netdb.h 1.30 03/12/04 SMI@(#)errno.h 1.17 03/01/03 SMI@(#)errno.h 1.20 00/01/12 SMI@(#)utsname.h 1.30 04/09/28 SMI@(#)inttypes.h 1.4 04/04/29 SMI@(#)inttypes.h 1.3 03/12/04 SMI@(#)int_const.h 1.5 04/09/28 SMI@(#)int_fmtio.h 1.6 04/09/28 SMI@(#)stdint.h 1.1 03/12/04 SMI@(#)processor.h 1.13 08/11/14 SMIacomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13@(#)types.h 1.86 07/09/20 SMI@(#)feature_tests.h 1.25 07/02/02 SMI@(#)ccompile.h 1.2 04/11/08 SMI@(#)isa_defs.h 1.29 08/06/06 SMI@(#)machtypes.h 1.11 04/09/28 SMI@(#)machtypes.h 1.2 04/09/28 SMI@(#)int_types.h 1.10 04/09/28 SMI@(#)select.h 1.19 04/01/28 SMI@(#)time_impl.h 1.11 05/05/19 SMI@(#)time.h 2.77 09/06/02 SMI@(#)time.h 1.45 08/01/09 SMI@(#)time_iso.h 1.4 04/09/07 SMI@(#)unistd.h 1.76 06/03/10 SMI@(#)unistd.h 1.43 06/03/10 SMI@(#)ipc.h 1.23 03/02/05 SMI@(#)fcntl.h 1.17 06/03/10 SMI@(#)fcntl.h 1.52 07/03/05 SMI@(#)errno.h 1.17 03/01/03 SMI@(#)errno.h 1.20 00/01/12 SMI@(#)signal.h 1.43 04/09/28 SMI@(#)signal_iso.h 1.1 99/08/09 SMI@(#)signal_iso.h 1.6 03/05/02 SMI@(#)signal.h 1.66 04/09/28 SMI@(#)siginfo.h 1.59 04/07/15 SMI@(#)machsig.h 1.11 03/09/26 SMI@(#)faultcode.h 1.16 09/07/02 SMI@(#)procset.h 1.25 04/07/16 SMI@(#)stdio.h 1.84 04/09/28 SMI@(#)stdio_iso.h 1.8 05/08/16 SMI@(#)va_list.h 1.15 04/11/19 SMI@(#)stdio_tag.h 1.4 04/09/28 SMI@(#)stdio_impl.h 1.15 07/03/05 SMI@(#)stdio_c99.h 1.2 04/03/29 SMI@(#)stdlib.h 1.51 04/06/30 SMI@(#)stdlib_iso.h 1.9 04/09/28 SMI@(#)stdlib_c99.h 1.2 04/03/29 SMI@(#)ctype.h 1.35 04/09/28 SMI@(#)ctype_iso.h 1.3 04/09/28 SMI@(#)ctype_c99.h 1.2 04/09/28 SMI@(#)socket.h 1.78 08/01/18 SMI@(#)uio.h 1.34 09/06/15 SMI@(#)socket_impl.h 1.1 05/08/02 SMI@(#)un.h 1.11 02/10/02 SMI@(#)if_dl.h 1.10 03/05/21 SMI@(#)netconfig.h 1.24 04/02/27 SMI@(#)in.h 1.55 09/05/27 SMI@(#)stream.h 1.115 08/07/22 SMI@(#)vnode.h 1.133 09/07/17 SMI@(#)t_lock.h 1.45 98/02/01 SMI@(#)machlock.h 1.25 04/07/19 SMI@(#)param.h 1.82 06/01/30 SMI@(#)mutex.h 1.21 07/04/04 SMI@(#)rwlock.h 1.9 98/02/18 SMI@(#)semaphore.h 1.5 98/02/01 SMI@(#)condvar.h 1.14 04/10/21 SMI@(#)rwstlock.h 1.4 04/11/09 SMI@(#)ksynch.h 1.6 97/10/22 SMI@(#)cred.h 1.27 06/05/03 SMI@(#)resource.h 1.37 07/02/07 SMI@(#)seg_enum.h 1.9 09/07/02 SMI@(#)kstat.h 1.22 07/02/02 SMI@(#)kmem.h 1.38 09/05/07 SMI@(#)vmem.h 1.12 05/06/27 SMI@(#)poll.h 1.28 98/11/23 SMI@(#)strmdep.h 1.10 98/01/06 SMI@(#)model.h 1.24 04/09/28 SMI@(#)strft.h 1.2 00/03/17 SMI@(#)byteorder.h 1.18 04/09/28 SMI@(#)inet.h 1.21 08/01/04 SMI@(#)netdb.h 1.30 03/12/04 SMI@(#)string.h 1.27 07/01/14 SMI@(#)string_iso.h 1.5 04/06/18 SMI@(#)inttypes.h 1.4 04/04/29 SMI@(#)inttypes.h 1.3 03/12/04 SMI@(#)int_limits.h 1.9 04/09/28 SMI@(#)int_const.h 1.5 04/09/28 SMI@(#)int_fmtio.h 1.6 04/09/28 SMI@(#)stdint.h 1.1 03/12/04 SMIacomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13@(#)stdio.h 1.84 04/09/28 SMI@(#)feature_tests.h 1.25 07/02/02 SMI@(#)ccompile.h 1.2 04/11/08 SMI@(#)isa_defs.h 1.29 08/06/06 SMI@(#)stdio_iso.h 1.8 05/08/16 SMI@(#)va_list.h 1.15 04/11/19 SMI@(#)stdio_tag.h 1.4 04/09/28 SMI@(#)stdio_impl.h 1.15 07/03/05 SMI@(#)stdio_c99.h 1.2 04/03/29 SMI@(#)types.h 1.86 07/09/20 SMI@(#)machtypes.h 1.11 04/09/28 SMI@(#)machtypes.h 1.2 04/09/28 SMI@(#)int_types.h 1.10 04/09/28 SMI@(#)select.h 1.19 04/01/28 SMI@(#)time_impl.h 1.11 05/05/19 SMI@(#)time.h 2.77 09/06/02 SMI@(#)time.h 1.45 08/01/09 SMI@(#)time_iso.h 1.4 04/09/07 SMI@(#)stat.h 1.11 04/09/28 SMI@(#)stat_impl.h 1.4 03/12/04 SMI@(#)stdlib.h 1.51 04/06/30 SMI@(#)stdlib_iso.h 1.9 04/09/28 SMI@(#)stdlib_c99.h 1.2 04/03/29 SMI@(#)stddef.h 1.18 04/09/28 SMI@(#)stddef_iso.h 1.2 03/03/06 SMI@(#)string.h 1.27 07/01/14 SMI@(#)string_iso.h 1.5 04/06/18 SMI@(#)strings.h 1.3 96/03/12 SMI@(#)inttypes.h 1.4 04/04/29 SMI@(#)inttypes.h 1.3 03/12/04 SMI@(#)int_limits.h 1.9 04/09/28 SMI@(#)int_const.h 1.5 04/09/28 SMI@(#)int_fmtio.h 1.6 04/09/28 SMI@(#)stdint.h 1.1 03/12/04 SMI@(#)unistd.h 1.76 06/03/10 SMI@(#)unistd.h 1.43 06/03/10 SMI@(#)fcntl.h 1.17 06/03/10 SMI@(#)fcntl.h 1.52 07/03/05 SMI@(#)errno.h 1.17 03/01/03 SMI@(#)errno.h 1.20 00/01/12 SMI@(#)signal.h 1.43 04/09/28 SMI@(#)signal_iso.h 1.1 99/08/09 SMI@(#)signal_iso.h 1.6 03/05/02 SMI@(#)signal.h 1.66 04/09/28 SMI@(#)siginfo.h 1.59 04/07/15 SMI@(#)machsig.h 1.11 03/09/26 SMI@(#)faultcode.h 1.16 09/07/02 SMI@(#)procset.h 1.25 04/07/16 SMI@(#)ipc.h 1.23 03/02/05 SMI@(#)socket.h 1.78 08/01/18 SMI@(#)uio.h 1.34 09/06/15 SMI@(#)socket_impl.h 1.1 05/08/02 SMI@(#)un.h 1.11 02/10/02 SMI@(#)if_dl.h 1.10 03/05/21 SMI@(#)netconfig.h 1.24 04/02/27 SMI@(#)in.h 1.55 09/05/27 SMI@(#)stream.h 1.115 08/07/22 SMI@(#)vnode.h 1.133 09/07/17 SMI@(#)t_lock.h 1.45 98/02/01 SMI@(#)machlock.h 1.25 04/07/19 SMI@(#)param.h 1.82 06/01/30 SMI@(#)mutex.h 1.21 07/04/04 SMI@(#)rwlock.h 1.9 98/02/18 SMI@(#)semaphore.h 1.5 98/02/01 SMI@(#)condvar.h 1.14 04/10/21 SMI@(#)rwstlock.h 1.4 04/11/09 SMI@(#)ksynch.h 1.6 97/10/22 SMI@(#)cred.h 1.27 06/05/03 SMI@(#)resource.h 1.37 07/02/07 SMI@(#)seg_enum.h 1.9 09/07/02 SMI@(#)kstat.h 1.22 07/02/02 SMI@(#)kmem.h 1.38 09/05/07 SMI@(#)vmem.h 1.12 05/06/27 SMI@(#)poll.h 1.28 98/11/23 SMI@(#)strmdep.h 1.10 98/01/06 SMI@(#)model.h 1.24 04/09/28 SMI@(#)strft.h 1.2 00/03/17 SMI@(#)byteorder.h 1.18 04/09/28 SMI@(#)tcp.h 1.18 05/12/21 SMI@(#)inet.h 1.21 08/01/04 SMI@(#)netdb.h 1.30 03/12/04 SMI@(#)sendfile.h 1.4 04/09/28 SMIacomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13acomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13acomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13acomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13acomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13acomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13acomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13@(#)stdio.h 1.84 04/09/28 SMI@(#)feature_tests.h 1.25 07/02/02 SMI@(#)ccompile.h 1.2 04/11/08 SMI@(#)isa_defs.h 1.29 08/06/06 SMI@(#)stdio_iso.h 1.8 05/08/16 SMI@(#)va_list.h 1.15 04/11/19 SMI@(#)stdio_tag.h 1.4 04/09/28 SMI@(#)stdio_impl.h 1.15 07/03/05 SMI@(#)stdio_c99.h 1.2 04/03/29 SMI@(#)stdlib.h 1.51 04/06/30 SMI@(#)stdlib_iso.h 1.9 04/09/28 SMI@(#)stdlib_c99.h 1.2 04/03/29 SMI@(#)string.h 1.27 07/01/14 SMI@(#)string_iso.h 1.5 04/06/18 SMI@(#)inttypes.h 1.4 04/04/29 SMI@(#)inttypes.h 1.3 03/12/04 SMI@(#)int_types.h 1.10 04/09/28 SMI@(#)int_limits.h 1.9 04/09/28 SMI@(#)int_const.h 1.5 04/09/28 SMI@(#)int_fmtio.h 1.6 04/09/28 SMI@(#)stdint.h 1.1 03/12/04 SMI@(#)types.h 1.86 07/09/20 SMI@(#)machtypes.h 1.11 04/09/28 SMI@(#)machtypes.h 1.2 04/09/28 SMI@(#)select.h 1.19 04/01/28 SMI@(#)time_impl.h 1.11 05/05/19 SMI@(#)time.h 2.77 09/06/02 SMI@(#)time.h 1.45 08/01/09 SMI@(#)time_iso.h 1.4 04/09/07 SMI@(#)sysinfo.h 1.31 10/04/13 SMI@(#)t_lock.h 1.45 98/02/01 SMI@(#)machlock.h 1.25 04/07/19 SMI@(#)param.h 1.82 06/01/30 SMI@(#)unistd.h 1.43 06/03/10 SMI@(#)mutex.h 1.21 07/04/04 SMI@(#)rwlock.h 1.9 98/02/18 SMI@(#)semaphore.h 1.5 98/02/01 SMI@(#)condvar.h 1.14 04/10/21 SMI@(#)kstat.h 1.22 07/02/02 SMIacomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13@(#)stdio.h 1.84 04/09/28 SMI@(#)feature_tests.h 1.25 07/02/02 SMI@(#)ccompile.h 1.2 04/11/08 SMI@(#)isa_defs.h 1.29 08/06/06 SMI@(#)stdio_iso.h 1.8 05/08/16 SMI@(#)va_list.h 1.15 04/11/19 SMI@(#)stdio_tag.h 1.4 04/09/28 SMI@(#)stdio_impl.h 1.15 07/03/05 SMI@(#)stdio_c99.h 1.2 04/03/29 SMI@(#)inttypes.h 1.4 04/04/29 SMI@(#)inttypes.h 1.3 03/12/04 SMI@(#)int_types.h 1.10 04/09/28 SMI@(#)int_limits.h 1.9 04/09/28 SMI@(#)int_const.h 1.5 04/09/28 SMI@(#)int_fmtio.h 1.6 04/09/28 SMI@(#)stdint.h 1.1 03/12/04 SMI@(#)unistd.h 1.76 06/03/10 SMI@(#)types.h 1.86 07/09/20 SMI@(#)machtypes.h 1.11 04/09/28 SMI@(#)machtypes.h 1.2 04/09/28 SMI@(#)select.h 1.19 04/01/28 SMI@(#)time_impl.h 1.11 05/05/19 SMI@(#)time.h 2.77 09/06/02 SMI@(#)time.h 1.45 08/01/09 SMI@(#)time_iso.h 1.4 04/09/07 SMI@(#)unistd.h 1.43 06/03/10 SMI@(#)strings.h 1.3 96/03/12 SMI@(#)string.h 1.27 07/01/14 SMI@(#)string_iso.h 1.5 04/06/18 SMI@(#)stdlib.h 1.51 04/06/30 SMI@(#)stdlib_iso.h 1.9 04/09/28 SMI@(#)stdlib_c99.h 1.2 04/03/29 SMI@(#)stddef.h 1.18 04/09/28 SMI@(#)stddef_iso.h 1.2 03/03/06 SMI@(#)errno.h 1.17 03/01/03 SMI@(#)errno.h 1.20 00/01/12 SMI@(#)kstat.h 1.4 93/06/30 SMI@(#)kstat.h 1.22 07/02/02 SMI@(#)sysinfo.h 1.31 10/04/13 SMI@(#)t_lock.h 1.45 98/02/01 SMI@(#)machlock.h 1.25 04/07/19 SMI@(#)param.h 1.82 06/01/30 SMI@(#)mutex.h 1.21 07/04/04 SMI@(#)rwlock.h 1.9 98/02/18 SMI@(#)semaphore.h 1.5 98/02/01 SMI@(#)condvar.h 1.14 04/10/21 SMI@(#)socket.h 1.78 08/01/18 SMI@(#)uio.h 1.34 09/06/15 SMI@(#)socket_impl.h 1.1 05/08/02 SMI@(#)un.h 1.11 02/10/02 SMI@(#)if_dl.h 1.10 03/05/21 SMI@(#)netconfig.h 1.24 04/02/27 SMI@(#)in.h 1.55 09/05/27 SMI@(#)stream.h 1.115 08/07/22 SMI@(#)vnode.h 1.133 09/07/17 SMI@(#)rwstlock.h 1.4 04/11/09 SMI@(#)ksynch.h 1.6 97/10/22 SMI@(#)cred.h 1.27 06/05/03 SMI@(#)resource.h 1.37 07/02/07 SMI@(#)seg_enum.h 1.9 09/07/02 SMI@(#)kmem.h 1.38 09/05/07 SMI@(#)vmem.h 1.12 05/06/27 SMI@(#)poll.h 1.28 98/11/23 SMI@(#)strmdep.h 1.10 98/01/06 SMI@(#)model.h 1.24 04/09/28 SMI@(#)strft.h 1.2 00/03/17 SMI@(#)byteorder.h 1.18 04/09/28 SMI@(#)netdb.h 1.30 03/12/04 SMIacomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13@(#)stdio.h 1.84 04/09/28 SMI@(#)feature_tests.h 1.25 07/02/02 SMI@(#)ccompile.h 1.2 04/11/08 SMI@(#)isa_defs.h 1.29 08/06/06 SMI@(#)stdio_iso.h 1.8 05/08/16 SMI@(#)va_list.h 1.15 04/11/19 SMI@(#)stdio_tag.h 1.4 04/09/28 SMI@(#)stdio_impl.h 1.15 07/03/05 SMI@(#)stdio_c99.h 1.2 04/03/29 SMI@(#)string.h 1.27 07/01/14 SMI@(#)string_iso.h 1.5 04/06/18 SMI@(#)types.h 1.86 07/09/20 SMI@(#)machtypes.h 1.11 04/09/28 SMI@(#)machtypes.h 1.2 04/09/28 SMI@(#)int_types.h 1.10 04/09/28 SMI@(#)select.h 1.19 04/01/28 SMI@(#)time_impl.h 1.11 05/05/19 SMI@(#)time.h 2.77 09/06/02 SMI@(#)time.h 1.45 08/01/09 SMI@(#)time_iso.h 1.4 04/09/07 SMI@(#)socket.h 1.78 08/01/18 SMI@(#)uio.h 1.34 09/06/15 SMI@(#)socket_impl.h 1.1 05/08/02 SMI@(#)un.h 1.11 02/10/02 SMI@(#)if_dl.h 1.10 03/05/21 SMI@(#)netconfig.h 1.24 04/02/27 SMI@(#)in.h 1.55 09/05/27 SMI@(#)stream.h 1.115 08/07/22 SMI@(#)vnode.h 1.133 09/07/17 SMI@(#)t_lock.h 1.45 98/02/01 SMI@(#)machlock.h 1.25 04/07/19 SMI@(#)param.h 1.82 06/01/30 SMI@(#)unistd.h 1.43 06/03/10 SMI@(#)mutex.h 1.21 07/04/04 SMI@(#)rwlock.h 1.9 98/02/18 SMI@(#)semaphore.h 1.5 98/02/01 SMI@(#)condvar.h 1.14 04/10/21 SMI@(#)rwstlock.h 1.4 04/11/09 SMI@(#)ksynch.h 1.6 97/10/22 SMI@(#)cred.h 1.27 06/05/03 SMI@(#)resource.h 1.37 07/02/07 SMI@(#)seg_enum.h 1.9 09/07/02 SMI@(#)kstat.h 1.22 07/02/02 SMI@(#)kmem.h 1.38 09/05/07 SMI@(#)vmem.h 1.12 05/06/27 SMI@(#)poll.h 1.28 98/11/23 SMI@(#)strmdep.h 1.10 98/01/06 SMI@(#)model.h 1.24 04/09/28 SMI@(#)strft.h 1.2 00/03/17 SMI@(#)byteorder.h 1.18 04/09/28 SMI@(#)socketvar.h 1.78 07/10/11 SMI@(#)file.h 1.70 07/03/05 SMI@(#)zone.h 1.21 10/01/08 SMI@(#)rctl.h 1.15 07/11/26 SMI@(#)ipc_rctl.h 1.1 07/02/07 SMI@(#)pset.h 1.6 08/11/14 SMI@(#)processor.h 1.13 08/11/14 SMI@(#)procset.h 1.25 04/07/16 SMI@(#)signal.h 1.66 04/09/28 SMI@(#)signal_iso.h 1.6 03/05/02 SMI@(#)siginfo.h 1.59 04/07/15 SMI@(#)machsig.h 1.11 03/09/26 SMI@(#)faultcode.h 1.16 09/07/02 SMI@(#)label.h 1.3 09/06/23 SMI@(#)netstack.h 1.3 09/01/06 SMI@(#)uadmin.h 1.31 07/01/14 SMI@(#)ksslapi.h 1.2 08/04/18 SMI@(#)inet.h 1.21 08/01/04 SMI@(#)if.h 1.38 07/03/20 SMI@(#)route.h 1.20 06/05/03 SMI@(#)label_macro.h 1.1 06/05/03 SMI@(#)unistd.h 1.76 06/03/10 SMI@(#)stdlib.h 1.51 04/06/30 SMI@(#)stdlib_iso.h 1.9 04/09/28 SMI@(#)stdlib_c99.h 1.2 04/03/29 SMI@(#)errno.h 1.17 03/01/03 SMI@(#)errno.h 1.20 00/01/12 SMI@(#)ioctl.h 1.9 92/07/14 SMI@(#)sockio.h 1.41 07/10/11 SMI@(#)ioccom.h 1.14 97/10/22 SMIacomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13@(#)string.h 1.27 07/01/14 SMI@(#)string_iso.h 1.5 04/06/18 SMI@(#)feature_tests.h 1.25 07/02/02 SMI@(#)ccompile.h 1.2 04/11/08 SMI@(#)isa_defs.h 1.29 08/06/06 SMI@(#)ctype.h 1.35 04/09/28 SMI@(#)ctype_iso.h 1.3 04/09/28 SMI@(#)ctype_c99.h 1.2 04/09/28 SMIacomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13@(#)string.h 1.27 07/01/14 SMI@(#)string_iso.h 1.5 04/06/18 SMI@(#)feature_tests.h 1.25 07/02/02 SMI@(#)ccompile.h 1.2 04/11/08 SMI@(#)isa_defs.h 1.29 08/06/06 SMI@(#)ctype.h 1.35 04/09/28 SMI@(#)ctype_iso.h 1.3 04/09/28 SMI@(#)ctype_c99.h 1.2 04/09/28 SMI@(#)stdlib.h 1.51 04/06/30 SMI@(#)stdlib_iso.h 1.9 04/09/28 SMI@(#)stdlib_c99.h 1.2 04/03/29 SMI@(#)if.h 1.38 07/03/20 SMI@(#)socket.h 1.78 08/01/18 SMI@(#)types.h 1.86 07/09/20 SMI@(#)machtypes.h 1.11 04/09/28 SMI@(#)machtypes.h 1.2 04/09/28 SMI@(#)int_types.h 1.10 04/09/28 SMI@(#)select.h 1.19 04/01/28 SMI@(#)time_impl.h 1.11 05/05/19 SMI@(#)time.h 2.77 09/06/02 SMI@(#)time.h 1.45 08/01/09 SMI@(#)time_iso.h 1.4 04/09/07 SMI@(#)uio.h 1.34 09/06/15 SMI@(#)socket_impl.h 1.1 05/08/02 SMI@(#)un.h 1.11 02/10/02 SMI@(#)if_dl.h 1.10 03/05/21 SMI@(#)netconfig.h 1.24 04/02/27 SMI@(#)in.h 1.55 09/05/27 SMI@(#)stream.h 1.115 08/07/22 SMI@(#)vnode.h 1.133 09/07/17 SMI@(#)t_lock.h 1.45 98/02/01 SMI@(#)machlock.h 1.25 04/07/19 SMI@(#)param.h 1.82 06/01/30 SMI@(#)unistd.h 1.43 06/03/10 SMI@(#)mutex.h 1.21 07/04/04 SMI@(#)rwlock.h 1.9 98/02/18 SMI@(#)semaphore.h 1.5 98/02/01 SMI@(#)condvar.h 1.14 04/10/21 SMI@(#)rwstlock.h 1.4 04/11/09 SMI@(#)ksynch.h 1.6 97/10/22 SMI@(#)cred.h 1.27 06/05/03 SMI@(#)resource.h 1.37 07/02/07 SMI@(#)seg_enum.h 1.9 09/07/02 SMI@(#)kstat.h 1.22 07/02/02 SMI@(#)kmem.h 1.38 09/05/07 SMI@(#)vmem.h 1.12 05/06/27 SMI@(#)poll.h 1.28 98/11/23 SMI@(#)strmdep.h 1.10 98/01/06 SMI@(#)model.h 1.24 04/09/28 SMI@(#)strft.h 1.2 00/03/17 SMI@(#)byteorder.h 1.18 04/09/28 SMI@(#)devid.h 1.14 08/05/21 SMI@(#)sunddi.h 1.180 09/06/01 SMI@(#)dditypes.h 1.41 08/02/14 SMI@(#)ddipropdefs.h 1.23 09/02/01 SMI@(#)devops.h 1.50 05/06/14 SMI@(#)buf.h 1.59 09/05/15 SMI@(#)types32.h 1.4 98/02/13 SMI@(#)as.h 1.94 10/04/07 SMI@(#)watchpoint.h 1.9 04/06/25 SMI@(#)copyops.h 1.5 04/06/25 SMI@(#)thread.h 1.156 09/10/09 SMI@(#)klwp.h 1.51 07/01/14 SMI@(#)signal.h 1.66 04/09/28 SMI@(#)signal_iso.h 1.6 03/05/02 SMI@(#)siginfo.h 1.59 04/07/15 SMI@(#)machsig.h 1.11 03/09/26 SMI@(#)faultcode.h 1.16 09/07/02 SMI@(#)pcb.h 1.25 09/10/04 SMI@(#)regset.h 1.9 06/05/12 SMI@(#)privregs.h 1.1 04/09/28 SMI@(#)privregs.h 1.3 06/05/12 SMI@(#)controlregs.h 1.14 09/06/15 SMI@(#)segments.h 1.6 07/02/02 SMI@(#)tss.h 1.5 04/09/28 SMI@(#)msacct.h 1.10 04/08/11 SMI@(#)ucontext.h 1.11 04/09/28 SMI@(#)lwp.h 1.34 04/09/28 SMI@(#)synch.h 1.41 08/02/19 SMI@(#)contract.h 1.2 04/09/28 SMI@(#)kcpc.h 1.7 07/10/12 SMI@(#)cpc_impl.h 1.13 07/10/12 SMI@(#)aio_req.h 1.7 00/05/22 SMI@(#)avl.h 1.11 06/03/10 SMI@(#)avl_impl.h 1.8 04/07/15 SMI@(#)seg.h 1.75 09/07/02 SMI@(#)hat.h 1.110 09/07/17 SMI@(#)page.h 1.181 09/06/15 SMI@(#)proc.h 1.209 09/06/09 SMI@(#)user.h 1.75 07/03/05 SMI@(#)timer.h 1.23 08/06/12 SMI@(#)utrap.h 1.1 03/04/21 SMI@(#)refstr.h 1.1 99/03/31 SMI@(#)rctl.h 1.15 07/11/26 SMI@(#)list.h 1.5 09/05/07 SMI@(#)list_impl.h 1.1 03/02/05 SMI@(#)door_impl.h 1.1 04/05/15 SMI@(#)ddidmareq.h 1.29 06/06/08 SMI@(#)ddimapreq.h 1.14 96/06/25 SMI@(#)mman.h 1.47 09/06/15 SMI@(#)ddidevmap.h 1.22 07/02/07 SMI@(#)ddifm.h 1.6 07/01/10 SMI@(#)nexusdefs.h 1.20 07/07/18 SMI@(#)ddi_intr.h 1.4 09/05/13 SMI@(#)ddi_intr_impl.h 1.11 09/05/13 SMI@(#)cmn_err.h 1.33 04/09/28 SMI@(#)ddi_impldefs.h 1.119 09/06/01 SMI@(#)autoconf.h 1.57 09/05/13 SMI@(#)obpdefs.h 1.6 06/03/10 SMI@(#)systm.h 1.144 10/05/05 SMI@(#)dacf_impl.h 1.3 03/12/09 SMI@(#)dacf.h 1.2 02/06/17 SMI@(#)ndifm.h 1.3 07/01/10 SMI@(#)ddifm_impl.h 1.9 09/01/08 SMI@(#)errorq.h 1.2 04/03/17 SMI@(#)nvpair.h 1.15 09/04/07 SMI@(#)errno.h 1.20 00/01/12 SMI@(#)va_list.h 1.15 04/11/19 SMI@(#)epm.h 1.50 09/05/28 SMI@(#)pm.h 1.24 09/05/28 SMI@(#)taskq.h 1.5 10/01/04 SMI@(#)ddi_isa.h 1.20 08/05/26 SMI@(#)ddi_implfuncs.h 1.54 08/12/01 SMI@(#)task.h 1.10 08/04/14 SMI@(#)project.h 1.14 07/09/26 SMI@(#)ipc_rctl.h 1.1 07/02/07 SMI@(#)zone.h 1.21 10/01/08 SMI@(#)pset.h 1.6 08/11/14 SMI@(#)processor.h 1.13 08/11/14 SMI@(#)procset.h 1.25 04/07/16 SMI@(#)label.h 1.3 09/06/23 SMI@(#)netstack.h 1.3 09/01/06 SMI@(#)uadmin.h 1.31 07/01/14 SMI@(#)devctl.h 1.17 08/11/14 SMI@(#)dma_engine.h 1.9 98/01/06 SMI@(#)sunpm.h 1.10 07/11/15 SMI@(#)sysevent.h 1.15 04/06/03 SMI@(#)u8_textprep.h 1.1 08/06/06 SMI@(#)libdevinfo.h 1.33 08/09/08 SMI@(#)errno.h 1.17 03/01/03 SMI@(#)sunmdi.h 1.17 08/11/27 SMI@(#)note.h 1.2 95/03/21 SMI@(#)esunddi.h 1.25 06/03/10 SMI@(#)openpromio.h 1.20 03/05/06 SMI@(#)devinfo_impl.h 1.22 06/06/11 SMI@(#)limits.h 1.59 04/08/24 SMI@(#)limits_iso.h 1.2 03/12/04 SMI@(#)int_limits.h 1.9 04/09/28 SMIacomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13@(#)stdio.h 1.84 04/09/28 SMI@(#)feature_tests.h 1.25 07/02/02 SMI@(#)ccompile.h 1.2 04/11/08 SMI@(#)isa_defs.h 1.29 08/06/06 SMI@(#)stdio_iso.h 1.8 05/08/16 SMI@(#)va_list.h 1.15 04/11/19 SMI@(#)stdio_tag.h 1.4 04/09/28 SMI@(#)stdio_impl.h 1.15 07/03/05 SMI@(#)stdio_c99.h 1.2 04/03/29 SMI@(#)errno.h 1.17 03/01/03 SMI@(#)errno.h 1.20 00/01/12 SMI@(#)math.h 2.24 04/10/23 SMI@(#)math_iso.h 1.9 04/10/23 SMI@(#)math_c99.h 1.9 04/11/01 SMI@(#)floatingpoint.h 2.9 04/10/23 SMI@(#)ieeefp.h 2.12 04/10/23 SMI@(#)stdlib.h 1.51 04/06/30 SMI@(#)stdlib_iso.h 1.9 04/09/28 SMI@(#)stdlib_c99.h 1.2 04/03/29 SMI@(#)string.h 1.27 07/01/14 SMI@(#)string_iso.h 1.5 04/06/18 SMI@(#)kstat.h 1.4 93/06/30 SMI@(#)types.h 1.86 07/09/20 SMI@(#)machtypes.h 1.11 04/09/28 SMI@(#)machtypes.h 1.2 04/09/28 SMI@(#)int_types.h 1.10 04/09/28 SMI@(#)select.h 1.19 04/01/28 SMI@(#)time_impl.h 1.11 05/05/19 SMI@(#)time.h 2.77 09/06/02 SMI@(#)time.h 1.45 08/01/09 SMI@(#)time_iso.h 1.4 04/09/07 SMI@(#)kstat.h 1.22 07/02/02 SMI@(#)systeminfo.h 1.19 04/07/16 SMI@(#)smbios.h 1.1 06/03/19 SMIacomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13@(#)string.h 1.27 07/01/14 SMI@(#)string_iso.h 1.5 04/06/18 SMI@(#)feature_tests.h 1.25 07/02/02 SMI@(#)ccompile.h 1.2 04/11/08 SMI@(#)isa_defs.h 1.29 08/06/06 SMI@(#)stdio.h 1.84 04/09/28 SMI@(#)stdio_iso.h 1.8 05/08/16 SMI@(#)va_list.h 1.15 04/11/19 SMI@(#)stdio_tag.h 1.4 04/09/28 SMI@(#)stdio_impl.h 1.15 07/03/05 SMI@(#)stdio_c99.h 1.2 04/03/29 SMI@(#)socket.h 1.78 08/01/18 SMI@(#)types.h 1.86 07/09/20 SMI@(#)machtypes.h 1.11 04/09/28 SMI@(#)machtypes.h 1.2 04/09/28 SMI@(#)int_types.h 1.10 04/09/28 SMI@(#)select.h 1.19 04/01/28 SMI@(#)time_impl.h 1.11 05/05/19 SMI@(#)time.h 2.77 09/06/02 SMI@(#)time.h 1.45 08/01/09 SMI@(#)time_iso.h 1.4 04/09/07 SMI@(#)uio.h 1.34 09/06/15 SMI@(#)socket_impl.h 1.1 05/08/02 SMI@(#)un.h 1.11 02/10/02 SMI@(#)if_dl.h 1.10 03/05/21 SMI@(#)netconfig.h 1.24 04/02/27 SMI@(#)in.h 1.55 09/05/27 SMI@(#)stream.h 1.115 08/07/22 SMI@(#)vnode.h 1.133 09/07/17 SMI@(#)t_lock.h 1.45 98/02/01 SMI@(#)machlock.h 1.25 04/07/19 SMI@(#)param.h 1.82 06/01/30 SMI@(#)unistd.h 1.43 06/03/10 SMI@(#)mutex.h 1.21 07/04/04 SMI@(#)rwlock.h 1.9 98/02/18 SMI@(#)semaphore.h 1.5 98/02/01 SMI@(#)condvar.h 1.14 04/10/21 SMI@(#)rwstlock.h 1.4 04/11/09 SMI@(#)ksynch.h 1.6 97/10/22 SMI@(#)cred.h 1.27 06/05/03 SMI@(#)resource.h 1.37 07/02/07 SMI@(#)seg_enum.h 1.9 09/07/02 SMI@(#)kstat.h 1.22 07/02/02 SMI@(#)kmem.h 1.38 09/05/07 SMI@(#)vmem.h 1.12 05/06/27 SMI@(#)poll.h 1.28 98/11/23 SMI@(#)strmdep.h 1.10 98/01/06 SMI@(#)model.h 1.24 04/09/28 SMI@(#)strft.h 1.2 00/03/17 SMI@(#)byteorder.h 1.18 04/09/28 SMI@(#)netdb.h 1.30 03/12/04 SMI@(#)inttypes.h 1.4 04/04/29 SMI@(#)inttypes.h 1.3 03/12/04 SMI@(#)int_limits.h 1.9 04/09/28 SMI@(#)int_const.h 1.5 04/09/28 SMI@(#)int_fmtio.h 1.6 04/09/28 SMI@(#)stdint.h 1.1 03/12/04 SMIacomp: Sun C 5.11 SunOS_i386 145355-01 2010/10/11as: Sun Compiler Common 12.2 SunOS_i386 2010/08/13ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.497netserver.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c netserver.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0netlib.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c netlib.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0M,netsh.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c netsh.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0Bnettest_bsd.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c nettest_bsd.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0Xnettest_dlpi.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c nettest_dlpi.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0/nnettest_unix.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c nettest_unix.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0nettest_xti.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c nettest_xti.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0nettest_sctp.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c nettest_sctp.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0nettest_sdp.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c nettest_sdp.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0nnettest_omni.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c nettest_omni.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0net_uuid.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c net_uuid.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0 netcpu_kstat10.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c netcpu_kstat10.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0Ynetrt_rtmget.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c netrt_rtmget.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0netdrv_solaris.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c netdrv_solaris.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.04netslot_solaris.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c netslot_solaris.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0MJnetsys_solaris.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c netsys_solaris.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0`netsec_none.c /home/t600359/dev/netperf-2.5.0/src /opt/solstudio12.2/prod/bin/cc -DHAVE_CONFIG_H -I. -I.. -lsocket -lnsl -lkstat -c netsec_none.cXa;R=Sun C 5.11 SunOS_i386 145355-01 2010/10/11;backend;raw;cd;DBG_GEN 5.3.0IC /home/t600359/dev/netperf-2.5.0/srcnetserver.cF@ /home/t600359/dev/netperf-2.5.0/srcnetlib.cE? /home/t600359/dev/netperf-2.5.0/srcnetsh.cKE /home/t600359/dev/netperf-2.5.0/srcnettest_bsd.cLF /home/t600359/dev/netperf-2.5.0/srcnettest_dlpi.cLF /home/t600359/dev/netperf-2.5.0/srcnettest_unix.cKE /home/t600359/dev/netperf-2.5.0/srcnettest_xti.cLF /home/t600359/dev/netperf-2.5.0/srcnettest_sctp.cKE /home/t600359/dev/netperf-2.5.0/srcnettest_sdp.cLF /home/t600359/dev/netperf-2.5.0/srcnettest_omni.cHB /home/t600359/dev/netperf-2.5.0/srcnet_uuid.cNH /home/t600359/dev/netperf-2.5.0/srcnetcpu_kstat10.cLF /home/t600359/dev/netperf-2.5.0/srcnetrt_rtmget.cNH /home/t600359/dev/netperf-2.5.0/srcnetdrv_solaris.cOI /home/t600359/dev/netperf-2.5.0/srcnetslot_solaris.cNH /home/t600359/dev/netperf-2.5.0/srcnetsys_solaris.cKE /home/t600359/dev/netperf-2.5.0/srcnetsec_none.c DD% DD% DD% DD% DD% DD% DD% DD% DD% DD% DD% DD% DD% DD% DD% DD% DD%.interp.SUNW_cap.hash.dynsym.dynstr.SUNW_version.rel.data.rel.bss.rel.plt.text.init.fini.rodata.rodata1.got.dynamic.bssf.symtab.strtab.annotate.comment.debug_info.debug_line.debug_abbrev.shstrtab o !"00)olKlK7 B|L|LA BLL(J BLL NTPTP`SWW Y_e  `m8`vLL{NN;OOggEggg) od8*A)0v 107070100000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000b00000000TRAILER!!!