[netperf-dev] Netperf 2.4.5 is released.

Rick Jones rick.jones2 at hp.com
Thu Jun 11 17:24:34 PDT 2009


Folks -

It has been entirely too long, but I've finally declared the release of netperf 
2.4.5.  You can obtain the sources either via subversion from:

http://www.netperf.org/svn/netperf2/tags/netperf-2.4.5

or you can obtain either a compressed tar or zip file from:

ftp://ftp.netperf.org/netperf

where you may chose from netperf-2.4.5.tar.bz2, netperf-2.4.5.tar.gz and 
netperf-2.4.5.zip.

Here is the top of:

http://www.netperf.org/svn/netperf2/tags/netperf-2.4.5/Release_Notes

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 <simonb at NetBSD.org>

*) 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.

happy benchmarking,

rick jones


More information about the netperf-dev mailing list