NETPERF.0. The Legal StuffCopyright (C) 1993,1994,1995 Hewlett-Packard CompanyALL RIGHTS RESERVED.The enclosed software and documention includes copyrighted works ofHewlett-Packard Co.

1. Netperf Usage

For as long as you comply with the followinglimitations, you are hereby authorized to (i) use, reproduce, andmodify the software and documentation, and to (ii) distribute thesoftware and documentation, including modifications, fornon-commercial purposes only.1. The enclosed software and documentation is made available at nocharge in order to advance the general development ofhigh-performance networking products.2. You may not delete any copyright notices contained in thesoftware or documentation. All hard copies, and copies insource code or object code form, of the software ordocumentation (including modifications) must contain at leastone of the copyright notices.3.

The enclosed software and documentation has not been subjectedto testing and quality control and is not a Hewlett-Packard Co.product. At a future time, Hewlett-Packard Co. May or may notoffer 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 ORDOCUMENTATION WILL NOT INFRINGE A THIRD PARTY'S INTELLECTUALPROPERTY RIGHTS. HP DOES NOT WARRANT THAT THE SOFTWARE ORDOCUMENTATION IS ERROR FREE. HP DISCLAIMS ALL WARRANTIES,EXPRESS AND IMPLIED, WITH REGARD TO THE SOFTWARE AND THEDOCUMENTATION.

HP SPECIFICALLY DISCLAIMS ALL WARRANTIES OFMERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.5. HEWLETT-PACKARD COMPANY WILL NOT IN ANY EVENT BE LIABLE FOR ANYDIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES(INCLUDING LOST PROFITS) RELATED TO ANY USE, REPRODUCTION,MODIFICATION, OR DISTRIBUTION OF THE SOFTWARE OR DOCUMENTATION.1. IntroductionNetperf is a benchmark that can be used to measure various aspects of networkingperformance. Its primary focus is on bulk data transfer and request/response performanceusing either TCP or UDP and the Berkeley Sockets interface. There are optional testsavailable to measure the performance of DLPI, Unix Domain Sockets, the Fore ATM API andthe HP HiPPI LLA interface.This tool is maintained and informally supported by the IND Networking Performance Team.It is NOT supported via any of the normal Hewlett-Packard support channels. You are freeto make enhancements and modifications to this tool.This document is organized (loosely) into several sections as follows:.

Section 1. Is what you are reading right now. Section 2. Describes how to get the netperf bits and how to set-up your system to runnetperf.

It also describes a simple way to verify that the installation has been successful. Section 3. Describes the design of netperf. Section 4. Describes netperf's bulk data transfer tests and their command line options. Section 5.

Describes netperf's request-response tests and their command options. Section 6.

Describes some of the supporting test types of netperf and their command lineoptions. Section 7. Provides a description of the global command-line options for netperf. Section 8. Provides some examples of netperf usage.

Section 9. Lists the changes and fixes in this revision of netperf. Section 10. Lists several known problems with this revision of netperf.

Section 11. Provides some troubleshooting assistance.We thank you in advance for your comments, and hope that you find this tool useful.HP-IND Networking Performance Team``How fast is it? It's so fast, that.' ;-)and DefinitionsYou may not be familiar with some of the conventions and definitions used by this document.Generally, items of particular importance, command line options, and commands will be inboldface type.

Filenames and command line items requiring user substitution will appear initalicized type.A sizespec is a one or two item list passed with a command line option that can set the valueof one or two netperf parameters. If you wish to set both parameters to separate values, itemsshould be separated by a comma - Eg ``parm1,parm2'.

If you wish to set the first parameterwithout altering the value of the second, you should follow the first item with a comma - Eg``parm1,'. Likewise, precede the item with a comma if you wish to set only the secondparameter - Eg ',parm2'. An item without a comma will set both parameters. This last modeis the one most frequently used.Netperf has two types of command line options.

The first are global command line options.They are essentially any option that is not tied to a particular test, or group of tests. An exampleof a global command line option is the test type. The second options are test specific options.These are options which are only applicable to a particular test. An example of a test specificoption would be the send socket buffer size for a TCPSTREAM test.

Global command lineoptions are specified first, test specific second. They must be separated from each other by a``-' (two dashes). If you wish to give test specific options only, they must be preceded by``-'. (EG./netperf - -m 1024)2. Installing NetperfNetperf is distributed in source form. This is to allow installation on systems other than thoseto which the authors have access.

There are two ways to install netperf. The first runs thenetperf server program, netserver, as a child of inetd, which requires that the installer ofnetperf be able to edit the files /etc/services and /etc/inetd.conf (or their equivalent). The secondis to run netserver as a standalone daemon.

This second method does not require editcapabilities on /etc/services and /etc/inetd.conf. But does mean that you must remember to runthe netserver program explicitly.This manual assumes that those wishing to measure networking performance already knowhow to use anonymous FTP.the netperf bits from the InternetFor those people connected to the Internet, netperf is available via WWW.

If you are notconnected to the Internet such that you can use WWW, then you may be able to retrieve netperfvia FTP or an FTP mail server. If all else fails, you can send email to Netperf Request.If you have a WWW browser, you can retrieve netperf from the Netperf Page.

It is located atthe URL Follow the links from that page.Netperf source bits are also available via anonymous FTP from ftp.cup.hp.com in the directorydist/networking/benchmarks. You should use binary mode transfers when bringing over the bitsas you will be grabbing the latest copy of this document along with the netperf C source files.NOTE: Older versions of netperf are available via anonymous FTP from col.hp.com underthe directory dist/networking/benchmarks/. It can also be found on other FTP servers on theInternet.While the netperf source bits can be placed anywhere on the system, this manual will assumethat the source bits are placed in the directory /opt/netperf/src. Previous revisions of netperfwere assumed to be placed in /usr/etc/netperf/src, but this has been changed to betteremphasize that netperf is not an official Hewlett-Packard product. You are free to placenetperf wherever you like, provided that you make the necessary modifications to the scripts.the bitsOnce you have placed the netperf source bits onto the system, it is necessary to compile themand perform some editing tasks. This section assumes that you have elected to install thebenchmark server, netserver, as a child of inetd.The netperf distribution includes a makefile which assumes the existence of the directory/opt/netperf.

If you do not wish to have netperf installed there, it will be necessary for you toedit the makefile. To assist in this process, obvious markers have been placed in the makefileto indicate what must be changed. Also, some systems require different compile switches andlibraries. For those systems where the requirements were known to the author, comments havebeen added to the makefile.Once the makefile is customized as needed, simply enter the command:$ make installfrom within the netperf source directory. The netperf executables will be compiled and copiedinto /opt/netperf or the place you specified in the makefile. Make will also copy the samplescript files into the same place and verify that they are set to be executable.Now that the executables have been created, it is necessary to edit the /etc/services and/etc/inetd.conf files.

If you have decided to keep the netperf executables someplace other than/opt/netperf, alter these lines accordingly. This editing step generally requires root access.

If youdo not have root access, or do not wish to install netperf as a child of inetd, skip to thesubsection titled 'Running netserver as a standalone Daemon.' Add this line to the /etc/services file:netperf12865/tcpThen add this line to the /etc/inetd.conf file:netperf stream tcp nowait root /opt/netperf/netserver netserverOnce the files have been edited, it is necessary to have inetd re-configure itself. On anHP-UX system, this is accomplished with the command:$ /etc/inetd -cOn some systems it is possible to get inetd to re-configure itself by sending it a SIGHUP withthe kill(2) command:$ kill -HUP On other systems it might be necessary to kill and re-start the inet daemon.

At this point, rootaccess is no longer needed and you can proceed to the verification step.the bitsTo verify the installation of netperf, simply execute the command/opt/netperf/netperfA TCPSTREAM test of 10 seconds duration should be performed over the loopbackinterface.netserver as a standalone DaemonIf you cannot install netperf as a child of inetd, you can run the netserver as a standalonedaemon. Simply execute netserver with the '-p ' option and it will happilystart accepting requests on the port number you specify.

If you specify a port number other thanthe normal netperf port number, you should remember to also specify '-p ' asa global command line option of netperf.CustomizationThe scripts provided with the netperf distribution are written with the assumption that netperfis installed in /opt/netperf. If you have decided to install netperf in a different location, you willneed to edit each of the script files and alter this line:NETHOME=/opt/netperfor one like it, to be something like:NETHOME=/my/netperf/location3. The Design of Netperf BasicsNetperf is designed around the basic client-server model. There are two executables -netperf and netserver.

Generally you will only execute the netperf program - the netserverprogram will be invoked by the other system's inetd.When you execute netperf, the first thing that will happen is the establishment of a controlconnection to the remote system. This connection will be used to pass test configurationinformation and results to and from the remote system. Regardless of the type of test being run,the control connection will be a TCP connection using BSD sockets.Once the control connection is up and the configuration information has been passed, aseparate connection will be opened for the measurement itself using the APIs and protocolsappropriate for the test. The test will be performed, and the results will be displayed.Netperf places no traffic on the control connection while a test is in progress. Certain TCPoptions, such as SOKEEPALIVE, if set as your system's default, may put packets out on thecontrol connection.UtilizationCPU utilization is a frequently requested metric of networking performance.

Unfortunately,it can also be one of the most difficult metrics to measure accurately. Netperf is designed touse one of several (perhaps platform dependent) CPU utilization measurement schemes.Depending on the CPU utilization measurement technique used, a unique single-letter codewill be included in the CPU portion of the test banner for both the local and remote systems.The default CPU measurement technique is based on pstat (-DPSTAT compilation only).This technique should work on most HP-UX systems, but it may under-report the CPUusage. The extent of this underreporting is not currently known.

When pstat is used to gatherCPU utilization information, a 'P' will be displayed in the test banner in the CPU column.A second measurement technique is based on a counter inserted into the HP-UX kernel's idleloop. Whenever the system goes completely idle (from the kernel's perspective), this counterstarts to increment.

When the system is not idle, the counter stops incrementing. This counter'svalue is retrieved by reading from /dev/kmem - a process which generally requires superuserprivileges. CPU utilization is determined by comparing the rate at which the counterincrements when the system is idle to the rate when a test is running.

The idle rate isre-computed for each test unless provided by the user (more information on CPU rates canbe found in Section 6.)This counter is not present in a production HP-UX kernel and must be compiled-in. Briefly,this entails adding a flag (-DIDLECNT) to the kernel makefile, removing a.o file, andrecompiling the kernel. This cannot be done on a system lacking kernel sources. Furthermore,this technique cannot be used at all on non-HP systems unless the vendors in questionimplement a similar technique. The kernel idle counter is considered highly accurate.

Whenit is used, a 'I' will be displayed in the test banner in the CPU column.One technique that could have been used was to fork a ``looperprocess' which would run ata low priority and count much like the kernel idle counter mechanism. Presumably, thisprocess would run only when there was nothing else for the system to do. Unfortunately, whilethis mechanism is likely more accurate than using pstat, it may have an impact on themeasurement. This mechanism is not currently available in netperf. When it is implemented,the letter 'L' will be the appropriate single-letter code.Other codes may be included in later versions of netperf. When the CPU utilizationmechanism is unknown, either a 'U' or a '?' Will be displayed.Great care should be exercised when looking at CPU utilization.

Be certain you are familiarwith the technique being used, and its implications. For example, a mechanism that is basedsolely on CPU charged to the netperf (netserver) process alone will likely under-report thereal CPU utilization SIGNIFICANTLY. Much network processing takes place away from theuser process context. Caveat Benchmarker!4. Using Netperf to measure bulk data transfer performanceThe most common use of netperf is measuring bulk data transfer performance. This is alsoreferred to as 'stream' or 'unidirectional stream' performance.

Essentially, these tests willmeasure how fast one system can send data to another and/or how fast that other system canreceive it.Stream PerformanceThe TCP stream performance test is the default test type for the netperf program. The simplesttest is performed by entering the command:/opt/netperf/netperf -H remotehostwhich will perform a 10 second test between the local system and the system identified byremotehost. The socket buffers on either end will be sized according to the systems' default andall TCP options (e.g. TCPNODELAY) will be at their default settings.To assist in measuring TCP stream performance, two script files are provided with the netperfdistribution. They are tcpstreamscript and tcprangescript. Tcpstreamscript will invokenetperf based on the setting of script variables controlling socket and send sizes.Tcprangescript will perform a similar set of tests, with the difference being that wheretcpstreamscript tests specific datapoints, tcprangescript will perform tests at points withina specified range.If you would like to perform tests other than those done by the scripts, you can invoke netperfmanually. Some of the options you will likely want to experiment with are:-s sizespecwhich will set the local send and receive socket buffer sizes to thevalue(s) specified.

Default: system default socket buffer sizes-S sizespecwhich behaves just like -s but for the remote system-m valueset the local send size to value bytes. Default: local socket buffersize-M valuewhich behaves like -m, setting the receive size for the remotesystem. Default: remote receive socket buffer size-l valueset the test length to value seconds when value is 0 and to value bytes when value is AAL5-b sizespecset the mean burst target and/or minimum in units of kilobitpackets. The first value is target and the second is minimum.Default: 0,0-d devspecset the name of the ATM device file to be opened. Default:/dev/atm-m valueset the local send size to value bytes. This must not be larger thanthe ATM MTU. Default: ATM MTU-M valuewhich behaves like -m, setting the receive size for the remotesystem.

Default: ATM MTU-p sizespecset the peak bandwidth target and/or minimum in units ofkilobits/s. The first value is target and the second it minimum.Default: 0,0 - network assigned-P sizespecset the mean bandwidth target and/or minimum in units ofkilobits/s. The first value is target and the second is minimum.Default: 0,0 - network assigned5. Using Netperf to measure request/response performanceRequest/response performance is the second area that can be investigated with netperf.Generally speaking, netperf request/response performance is quoted as 'transactions/s' fora given request and response size. A transaction is defined as the exchange of a single requestand a single response. From a transaction rate, one can infer one way and round-trip averagelatency.Request/Response PerformanceThe TCP request/response test can be invoked with netperf though the use of the -t optionwith an argument of TCPRR. So, a ``default' request/response command would looksomething like this:$ /opt/netperf/netperf -H remotehost -t TCPRRand will use the system default socket buffer sizes, a default request size of 1 byte, and a defaultresponse size of 1 byte.As with the stream performance tests, a script is available to assist you in generating TCPrequest/response performance numbers.

It is called tcprrscript. However, if you should needto generate numbers at points of you own choosing, these command line options will be of use:-r sizespecset the request and/or response sizes based on sizespec.-l valueset the test duration based on value. For value 0, test durationwill be value seconds. Otherwise, test duration will be value transactions.-s sizespecwhich will set the local send and receive socket buffer sizes to thevalue(s) specified.

Default: system default socket buffer sizes-S sizespecwhich behaves just like -s but for the remote system-D set the TCPNODELAY option to true on both systemsThe request and response sizes will be the buffer sizes posted to send and receive. The -m and-M options are not meaningful for a TCPRR test. As TCP is a stream protocol and not amessage protocol, it is necessary to loop on receives until the entire message is delivered.

Thebuffer pointer passed to the first receive for an individual transaction will be aligned and offsetas requested by the user. It will be incremented by the number of bytes received each time untilthe entire request/response is received. The buffer pointer will be re-aligned and offset forthe next transaction.Request/Response PerformanceUDP request/response performance works just like TCP request/response performance. Allthe options available there are present here with the exception of the -D option;TCPNODELAY has no meaning for a UDP test. To invoke a UDP request/response test, usean argument of UDPRR with the -t option to produce a command like something like this:$ /opt/netperf/netperf -H remotehost -t UDPRRAgain, a script is provided which will generate results for some of the more commondatapoints.

It is named udprrscript.Connection Oriented Request/Response PerformanceNOTE: DLPI tests are not compiled into netperf by default. If you wish to measure theperformance of DLPI, you must recompile netperf and netserver with -DDODLPI addedto the makefile.A DLPI Connection Oriented Request/Response test (DLCORR) looks much the same asany other request/response test. It performs a request/response test over a reliable connection.As with the other DLPI tests, there is no segmentation and reassembly, so all request and/orresponse sizes must be less than or equal to the link MTU.A simple DLCORR test invocation would look something like this:$ /opt/netperf/netperf -H remotehost -t DLCORRHere are some of the DLPI-specific command line options:-D devspecspecify the local and/or remote DLPI device file name(s)(fully-qualified). Syntax is the same as that of a sizespec.-p ppaspecset the local and/or remote DLPI PPA(s). Syntax is the same asthat of a sizespec.-r sizespecspecify the request and/or response sizes, in bytes, for the test.-s valuespecify the 802.2 SAP for the test. This should not conflict withany assigned SAP's.-w sizespecspecify the local send/recv window sizes in frames (whereavailable).-W sizespecspecify the remote send/recv window sizes in frames (whereavailable).Connectionless Request/Response PerformanceNOTE: DLPI tests are not compiled into netperf by default.

If you wish to measure theperformance of DLPI, you must recompile netperf and netserver with -DDODLPI addedto the makefile.A DLPI Connectionless Request/Response test (DLCLRR) looks much the same as anyother request/response test. It performs a request/response test over an unreliable connection.However, netperf does not have any sort of retransmission mechanism, so packet loss with thistest will result in dramatically lowered performance results. As with the other DLPI tests, thereis no segmentation and reassembly, so all request and/or response sizes must be less than orequal to the link MTU.A simple DLCLRR test invocation would look something like this:$ /opt/netperf/netperf -H remotehost -t DLCLRRHere are some of the DLPI-specific command line options:-D devspecspecify the local and/or remote DLPI device file name(s)(fully-qualified). Syntax is the same as that of a sizespec.-p ppaspecset the local and/or remote DLPI PPA(s). Syntax is the same asthat of a sizespec.-r sizespecspecify the request and/or response sizes, in bytes, for the test.-s valuespecify the 802.2 SAP for the test.

This should not conflict withany assigned SAP's.-w sizespecspecify the local send/recv window sizes in frames (whereavailable).-W sizespecspecify the remote send/recv window sizes in frames (whereavailable).Domain Stream Socket Request/Response PerformanceNOTE: Unix Domain Socket tests are not compiled into netperf by default. If you wish tomeasure the performance of Unix Domain Sockets, you must recompile netperf and netserverwith -DDOUNIX added to the makefile.A Unix Domain Stream Socket Request/Response test (STREAMRR) is very much like aTCPRR test.The STREAMRR test command line would look something like this:$ /opt/netperf/netperf -t STREAMRRThe -H global command line option is not valid for a Unix Domain Socket test and shouldnot be specified.Here are some of the Unix Domain-specific command line options for theSTREAMSTREAM test:-p dirspecset the directory where pipes will be created. Default: systemdefault for the tempnam call-r sizespecwhich will set the request and response sizes to the value(s)specified. Default: 1 byteDomain Datagram Socket Request/Response PerformanceNOTE: Unix Domain Socket tests are not compiled into netperf by default.

If you wish tomeasure the performance of Unix Domain Sockets, you must recompile netperf and netserverwith -DDOUNIX added to the makefile.The Simplest Unix Domain Datagram Socket Request/Response (DGRR) test commandline would look something like this:$ /opt/netperf/netperf -t DGSTREAMThe -H global command line option is not valid for a Unix Domain Socket test and shouldnot be specified. Here are some of the test specific command line options available in aDGSTREAM test.-p dirspecset the directory where pipes will be created.

Default: systemdefault for the tempnam call-r sizespecset the request and/or response sizes to the value(s) specified.Default: 1 byteATM API Request/Response PerformanceNOTE: Fore ATM API tests are not compiled into netperf by default. If you wish to measurethe performance of connections over the Fore ATM API, you must recompile netperf andnetserver with -DDOFORE added to the makefile.A Fore ATM API Request/Response test (FORERR) is very much like a UDPRR test.The simplest FORERR test command line would look something like this:$ /opt/netperf/netperf -t FORERR -H remotehostHere are some of the test specific command line options applicable to a FORESTREAMtest.-a aaluse the ATM Adaptation Layer number aal to encapsulatepackets. Specifying 3 or 4 will yield AAL3/4, and 5 will yieldAAL5. Default: 5 - AAL5-b sizespecset the mean burst target and/or minimum in units of kilobitpackets.

The first value is target and the second is minimum.Default: 0,0-d devspecset the name of the ATM device file to be opened. Default:/dev/atm-p sizespecset the peak bandwidth target and/or minimum in units ofkilobits/s. The first value is target and the second it minimum.Default: 0,0 - network assigned-P sizespecset the mean bandwidth target and/or minimum in units ofkilobits/s.

The first value is target and the second is minimum.Default: 0,0 - network assigned-r sizespecset the request and/or response sizes to the values specifiedDefault: 1 byte6. Other Netperf testsApart from the usual performance tests, netperf contains some tests that can be used tostreamline measurements. These tests range from CPU rate calibration (present) to hostidentification (future enhancement).rate calibrationNOTE: This discussion of calibration is germane only for those systems with the Kernel IdleCounter in place. It is not germane for CPU utilization measured with pstat.

If in the futurea looper process is introduced, this discussion would be germane for it as well.In this context, a CPU rate is expressed not in clock frequencies, MIPS or MFLOPS, but simplyhow fast the system can count. There are two CPU rate calibrations tests. The first measuresand displays the CPU rate for the local system. It is called LOCCPU.

The second test,REMCPU, is exactly the same, except that it works on the system specified with the -Hcommand line option.In and of themselves, these two tests are only arcanely interesting. However, they can be usedto greatly speed-up test scripts. Remember that for CPU measurements, it is necessary to``calibrate' the CPU or determine how fast it can count.

This process takes forty (40) secondsfor the local system and forty (40) seconds for the remote system. One can save the results ofthe CPU tests in shell variables and then use them as arguments to the -c and -C commandline options. Passing-in a rate with the -c or -C option tells netperf that you already knowthe CPU rate, so it can skip the calibration steps. For example, the following shell fragmentwill determine the local CPU rate and use that for subsequent tests:$ LOCRATE=`/opt/netperf/netperf -t LOCCPU`$ /opt/netperf/netperf -H somehost -c $LOCRATEYou should remember that CPU rates will vary from system to system. Generally, the besttrade-off between time and accuracy is to perform the calibrations once in each script orsession. The default scripts provided will use the LOCCPU and REMCPU tests to reducethe time overhead of CPU calibration.7.

Netperf Command-line Options ReferenceThis section describes each of the global command-line options available in the netperfprogram. Essentially, it is an expanded version of the usage information displayed by netperfwhen invoked with the -h option in global command line option area.Options SyntaxRevision 1.8 of netperf introduced enough new functionality to overrun the English alphabetfor mnemonic command line option names. For this reason, command-line options were splitin Revision 1.8.

This split remains in Revision 1.9alpha. There are two types of netperfcommand-line options. They are ``global' and ``test-specific.' Both types are entered on thesame command line, but they must be separated by a ``-' for correct parsing.

Globalcommand line options come first, followed by test-specific. If only test-specific options areto be specified, they must be preceded by ``-' or the results will be undefined.Options-asizespecThis option allows you to alter the send and receive bufferalignments on the local system. Changing the alignment of thebuffers can force the system to use different copying schemes,which can have a measurable impact on performance. If the pagesize for the system was 4096 bytes, and you wanted to pass pagealigned buffers beginning on page boundaries, you could use ``-a4096'. The units for this option are whole bytes. Default: 8 bytes-AsizespecThis option is identical to the -a option with the exception thatthe alignments are altered for the remote system.-bsizeThis option (-DINTERVALS compilation only) sets the size ofa burst of packets in a STREAM test.

This can be used to 'pace'the send rate when there is no flow-control provided by theprotocol being measured.-crateThis option will request CPU utilization and service demandcalculations for the local system. If the optional rate parameteris specified, netperf will use that instead of calculating the rateitself. For more information on CPU utilization measurementswith netperf, please consult Section 3. Default: no CPUmeasurements-CrateThis option is identical to the -c option with the exception thatit requests CPU utilization for the remote system.-d This option will increase the quantity of debugging outputdisplayed during a test. If debugging is set high enough, it mayhave a measurable impact on performance. Debugginginformation for the local system (the one running netperf) isprinted to stdout. Debugging information for the remote system(the one running netserver) is sent to the file /tmp/netperf.debugDefault: no debugging-fGMKgmkThis option can be used to change the units of measure for streamtests.

The ``G', ``M', and ``K' arguments will set the output unitsto 230, 220, and 210 bytes/s respectively. The ``g', ``m', and ``k'arguments will set the output units to 109, 106, and 103 bits/srespectively. Default: m - 106 bits/s)-h This option causes netperf to display its usage string and exit.-HremotehostThis option sets the name of the remote system.

It can bespecified as either a hostname (e.g. Foo.bar.baz) or an IP address(e.g. Default: localhost-ltestlenWith this option you can control the length of the test. If youspecify a positive value for testlen, the test will run for that manyseconds. If you specify a negative value, the test will run for thatmany transactions for a request/response test, or that many bytesfor a stream test.

Some tests can only be timed. Default: 10seconds-osizespecThe value passed with this option will be used as an offset fromthe alignment specified with the -a option. With this option youcould, for example, pass buffers to the system that began 3 bytesafter the beginning of a 4KB page (-a 4096 -o 3) Default: 0bytes-OsizespecThis option behaves just like the -o option but on the remotesystem. It works in conjunction with the -A option.

Default: 0bytes-pportnumYou should use this option when the netserver program will bewaiting at a port other than the default. This might be the case ifyou run netserver as a standalone process rather than a child ofinetd.-P0 1If you do not want the test banner to be displayed, then use thisoption with an argument of 0.

An situation where this might beuseful would be where you repeat the same test configurationseveral times and do not want the banners cluttering things up.Default: 1 - display test banners-ttestnameYou should use this option to specify the test you wish to perform.As of this writing, the valid testnames are TCPSTREAM,TCPRR, UDPSTREAM, UDPRR, DLCOSTREAM,DLCORR, DLCLSTREAM, DLCLRR,STREAMSTREAM, STREAMRR, DGSTREAM,DGRR, FORESTREAM, FORERR, HIPPISTREAM,HIPPIRR LOCCPU, and REMCPU. Default:TCPSTREAM-vverbosityThis option can be used to set the verbosity level for the test. Itcan be used in conjunction with the -P option. If the verbosity isset to 0, then only the result of the test will be displayed.

If CPUutilization numbers are requested for the local system, the resultof the test will be local service demand. If remote CPU utilizationis requested, then the result will be remote service demand.Otherwise, the result will be the measured thruput.-V This option will attempt to enable the copy-avoidance featuresof HP-UX 9.0 networking. Default: no copy-avoidanceattempted-wtimeThis option (-DINTERVALS compilation only) will set theinter-burst time to time milliseconds. The actual wait time maydiffer depending on the resolution of timers on the system beingmeasured.8. Netperf examples NOTE: These examples are from an older version of netperf and do not represent the splitbetween global and test specific command line options.The next few pages contain annotated screen dumps of example netperf runs. After examining these examples, you should have a fairly good idea of how to interpret the output of netperf and what effect certain options have on that output. These examples are from a revision of netperf which used a different command line option syntax.

Netperf Usage

First, TCPSTREAM tests.This next set of examples is taken from some UDPSTREAM tests. You should notice right away that the output format is slightly different as there can be UDP sends that ``fail' without there being a connection loss.

Also, since every UDP datagram sent is not always ``sent' or received, there are more statistics displayed - one line for local statistics and a second line for remote statistics.This third set of examples is taken from some.RR tests. These tests use a two-line results format much like that of the UDPSTREAM tests. The only exception is that there are no provisions made for displaying lost packets, as there are not to be any.9.

Changes and Fixes in this Release of NetperfRevision 2.0 of netperf contains the following changes and fixes:. On some systems, running netserver as a standalone daemon would result in theaccumulation of defunct or zombie processes. A call to waitpid has been added tonetserver so it can 'reap' its child processes when they exit. The option of confidence intervals has been added to give more assurance that theresults displayed by netperf are accurate and repeatable. While this will help, it is byno means an ironclad guarantee.

This is an experiment. The feature has been addedto the BSD tests only. If they are popular enough, they will be added to the other testsuites as time permits. The test banner output has been modified to give a better indication of the commandline options used.

Also, if CPU utilization measurements are requested, a special lettercode will be printed in the headers indicating the type of CPU measurement used. Moreinformation on this feature can be found in Section 3. The scripts which ship with netperf have been modified to be more 'netperf databasefriendly.' For each datapoint, the netperf command used is echoed to allowcut-and-paste into the netperf data submittal form.

Also, each datapoint is displayedwith a full set of test banners - again to facilitate results submission to the database.The netperf results database can be accessed with a forms-capable WWW browser atthe URL The control connection is closed gracefully in a manner similar to that used in theTCPSTREAM test.

Is a cool little utility that I discovered while working with. It's technically a network benchmarking tool, but it's fun to use to hammer your network with load and test out the bandwidth control features provided by network virtualization.Netperf used to be available in the now decommissioned contrib repository. That's OK, it's easy enough to build. Building Netperf for SolarisIf you want to save yourself the steps below, just save the following binaries to your /usr/bin directory:. Here are the from the Netperf manual.

At the time of this writing the latest stable build is. Extract the archive:bleonard@solaris:/Downloads$ tar -xvf netperf-2.4.5.tar.bz2 netperf-2.4.5/ netperf-2.4.5/src/. Netperf-2.4.5/doc/examples/udpstreamscript netperf-2.4.5/doc/netperf.info. Make sure you have gcc-3 and header-math installed:bleonard@solaris:$ pkg list gcc-3 header-math NAME (PUBLISHER) VERSION STATE UFOXI developer/gcc-3 3.4.3-0.151.0.1 installed - system/library/math/header-math 0.5.11-0.151.0.1 installed -.

Run configure, overriding the default install directory of /usr/local to /usr:bleonard@solaris:/Downloads/netperf-2.4.5$./configure -prefix=/usr checking build system type. Config.status: executing depfiles commands. Run make:bleonard@solaris:/Downloads/netperf-2.4.5$ make make all-recursive make1: Entering directory `/home/bleonard/Downloads/netperf-2.4.5'.

Make1: Leaving directory `/home/bleonard/Downloads/netperf-2.4.5'. The run make install:bleonard@solaris:/Downloads/netperf-2.4.5$ sudo make install Password: Making install in src make1: Entering directory `/home/bleonard/Downloads/netperf-2.4.5/src'. Bleonard@solaris:$ sudo cp /usr/bin/netserver /zones/myzone/root/usr/bin/.And then start the netserver:bleonard@solaris:$ sudo zlogin myzone /usr/bin/netserver Password: Starting netserver at port 12865 Starting netserver at hostname 0.0.0.0 port 12865 and family AFUNSPECNow let's test the connection between the global and local zone:bleonard@solaris:$ netperf -H 10.0.1.25 TCP STREAM TEST from::ffff:0.0.0.0 (0.0.0.0) port 0 AFINET to::ffff:10.0.1.25 (10.0.1.25) port 0 AFINET Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 12 49152.31Here we can see the throughput between my zones is 1722 Mbit/s. Now let's reduce the max bandwidth of the virtual NIC to 500 Mbit/s and try the test again:bleonard@solaris:$ sudo dladm set-linkprop -p maxbw=500 myzone0 bleonard@solaris:$ dladm show-vnic LINK OVER SPEED MACADDRESS MACADDRTYPE VID myzone0 e1000g0 500 2:8:20:59:0:b5 random 0 bleonard@solaris:$ netperf -H 10.0.1.25 TCP STREAM TEST from::ffff:0.0.0.0 (0.0.0.0) port 0 AFINET to::ffff:10.0.1.25 (10.0.1.25) port 0 AFINET Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs.

10^6bits/sec 12 49152 10.00 482.77Or at a ridiculously low 2 Mbit/s:bleonard@solaris:$ sudo dladm set-linkprop -p maxbw=2 myzone0 bleonard@solaris:$ netperf -H 10.0.1.25 TCP STREAM TEST from::ffff:0.0.0.0 (0.0.0.0) port 0 AFINET to::ffff:10.0.1.25 (10.0.1.25) port 0 AFINET Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 12 49152 10.38 1.07Good stuff.I've just scratched the surface of Netperf, but this simple introduction suits my purposes for testing network virtualization.

For more fun check out the.