head	1.4;
access;
symbols
	RELENG_8_4:1.4.0.2
	RELENG_9_1_0_RELEASE:1.3.2.1.4.2
	RELENG_9_1:1.3.2.1.0.4
	RELENG_9_1_BP:1.3.2.1
	RELENG_8_3_0_RELEASE:1.1.2.1.8.1
	RELENG_8_3:1.1.2.1.0.8
	RELENG_8_3_BP:1.1.2.1
	RELENG_9_0_0_RELEASE:1.3.2.1.2.1
	RELENG_9_0:1.3.2.1.0.2
	RELENG_9_0_BP:1.3.2.1
	RELENG_9:1.3.0.2
	RELENG_9_BP:1.3
	RELENG_8_2_0_RELEASE:1.1.2.1.6.1
	RELENG_8_2:1.1.2.1.0.6
	RELENG_8_2_BP:1.1.2.1
	RELENG_8_1_0_RELEASE:1.1.2.1.4.1
	RELENG_8_1:1.1.2.1.0.4
	RELENG_8_1_BP:1.1.2.1
	RELENG_8_0_0_RELEASE:1.1.2.1.2.1
	RELENG_8_0:1.1.2.1.0.2
	RELENG_8_0_BP:1.1.2.1
	RELENG_8:1.1.0.2
	RELENG_8_BP:1.1;
locks; strict;
comment	@# @;


1.4
date	2012.11.17.01.54.11;	author svnexp;	state Exp;
branches
	1.4.2.1;
next	1.3;

1.3
date	2010.06.22.10.45.35;	author rwatson;	state Exp;
branches
	1.3.2.1;
next	1.2;

1.2
date	2010.06.05.22.59.37;	author rwatson;	state Exp;
branches;
next	1.1;

1.1
date	2009.03.10.14.52.17;	author rwatson;	state Exp;
branches
	1.1.2.1;
next	;

1.4.2.1
date	2012.11.17.01.54.11;	author svnexp;	state dead;
branches;
next	1.4.2.2;

1.4.2.2
date	2013.03.28.13.05.59;	author svnexp;	state Exp;
branches;
next	;

1.3.2.1
date	2011.09.23.00.51.37;	author kensmith;	state Exp;
branches
	1.3.2.1.2.1
	1.3.2.1.4.1;
next	1.3.2.2;

1.3.2.2
date	2012.11.17.11.37.36;	author svnexp;	state Exp;
branches;
next	;

1.3.2.1.2.1
date	2011.11.11.04.20.22;	author kensmith;	state Exp;
branches;
next	1.3.2.1.2.2;

1.3.2.1.2.2
date	2012.11.17.08.37.32;	author svnexp;	state Exp;
branches;
next	;

1.3.2.1.4.1
date	2012.08.05.23.54.33;	author kensmith;	state Exp;
branches;
next	1.3.2.1.4.2;

1.3.2.1.4.2
date	2012.11.17.08.48.24;	author svnexp;	state Exp;
branches;
next	;

1.1.2.1
date	2009.08.03.08.13.06;	author kensmith;	state Exp;
branches
	1.1.2.1.2.1
	1.1.2.1.4.1
	1.1.2.1.6.1
	1.1.2.1.8.1;
next	1.1.2.2;

1.1.2.2
date	2012.11.17.10.37.14;	author svnexp;	state Exp;
branches;
next	;

1.1.2.1.2.1
date	2009.10.25.01.10.29;	author kensmith;	state Exp;
branches;
next	;

1.1.2.1.4.1
date	2010.06.14.02.09.06;	author kensmith;	state Exp;
branches;
next	;

1.1.2.1.6.1
date	2010.12.21.17.09.25;	author kensmith;	state Exp;
branches;
next	;

1.1.2.1.8.1
date	2012.03.03.06.15.13;	author kensmith;	state Exp;
branches;
next	1.1.2.1.8.2;

1.1.2.1.8.2
date	2012.11.17.08.25.48;	author svnexp;	state Exp;
branches;
next	;


desc
@@


1.4
log
@Switching exporter and resync
@
text
@tcpp -- Parallel TCP Exercise Tool

This is a new tool, and is rife with bugs.  However, it appears to create
even more problems for device drivers and the kernel, so that's OK.

This tool generates large numbers of TCP connections and stuffs lots of data
into them.  One binary encapsulates both a client and a server.  Each of the
client and the server generates a certain number of worker processes, each of
which in turn uses its own TCP port.  The number of server processes must be
>= the number of client processes, or some of the ports required by the
client won't have a listener.  The client then proceeds to make connections 
and send data to the server.  Each worker multiplexes many connections at
once, up to a maximum parallelism limit.  The client can use one or many IP
addresses, in order to make more 4-tuples available for testing, and will
automatically spread the load of new connections across available source
addresses.

You will need to retune your TCP stack for high volume, see Configuration
Notes below.

The server has very little to configure, use the following command line
flags:

  -s                           Select server mode
  -p <numprocs>                Number of workers, should be >= client -p arg
  -r <baseport>                Non-default base TCP port, should match client
  -T                           Print CPU usage every ten seconds
  -m <maxconnectionsperproc>   Maximum simultaneous connections/proc, should
                               be >= client setting.

Typical use:

  ./tcpp -s -p 4 -m 1000000

This selects server mode, four workers, and at most 1 million TCP connections
per worker at a time.

The client has more to configure, with the following flags:

  -c <remoteIP>                Select client mode, and specific dest IP
  -C                           Print connections/second instead of GBps
  -P                           Pin each worker to a CPU
  -M <localIPcount>            Number of sequential local IPs to use; req. -l
  -T                           Include CPU use summary in stats at end of run
  -b <bytespertcp>             Data bytes per connection
  -l <localIPbase>             Starting local IP address to bind
  -m <maxtcpsatonce>           Max simultaneous conn/worker (see server -m)
  -p <numprocs>                Number of workers, should be <= server -p
  -r <baseport>                Non-default base TCP port, should match server
  -t <tcpsperproc>             How many connections to use per worker
  
Typical use:

  ./tcpp -c 192.168.100.201 -p 4 -t 100000 -m 10000 -b 100000 \
    -l 192.168.100.101 -M 4

This creates four workers, each of which will (over its lifetime) set up and
use 100,000 TCP connections carrying 100K of data, up to 10,000 simultaneous
connection at any given moment.  tcpp will use four source IP addresses,
starting with 192.168.100.101, and all connections will be to the single
destination IP of 192.168.100.201.

Having (p) <= the number of cores is advisable.  When multiple IPs are used
on the client, they will be sequential starting with the localIPbase set with
-l.

Known Issues
------------

The bandwidth estimate doesn't handle failures well.  It also has serious
rounding errors and probably conceptual problems.

It's not clear that kevent() is "fair" to multiple connections.

Rather than passing the length for each connection, we might want to pass
it once with a control connection up front.  On the other hand, the server
is quite dumb right now, so we could take advantage of this to do size
mixes.

Configuration Notes
-------------------

In my testing, I use loader.conf entries of:

kern.ipc.maxsockets=1000000
net.inet.tcp.maxtcptw=3000000
kern.ipc.somaxconn=49152
kern.ipc.nmbjumbo16=262144
kern.ipc.nmbjumbo9=262144
kern.ipc.nmbjumbop=262144
kern.ipc.nmbclusters=262144
net.inet.tcp.syncache.cachelimit=65536
net.inet.tcp.syncache.bucketlimit=512

# May be useful if you can't use multiple IP addresses
net.inet.ip.portrange.first=100

# For running !multiq, do this before loading the driver:
kenv hw.cxgb.singleq="1"

kldload if_cxgb

# Consider turning off TSO and/or adjusting the MTU for some scenarios:
ifconfig cxgb0 -tso
ifconfig cxgb0 mtu 1500


$FreeBSD: head/tools/tools/netrate/tcpp/README 209428 2010-06-22 10:45:35Z rwatson $
@


1.4.2.1
log
@file README was added on branch RELENG_8_4 on 2013-03-28 13:05:59 +0000
@
text
@d1 108
@


1.4.2.2
log
@## SVN ## Exported commit - http://svnweb.freebsd.org/changeset/base/248810
## SVN ## CVS IS DEPRECATED: http://wiki.freebsd.org/CvsIsDeprecated
@
text
@a0 99
tcpp -- Parallel TCP Exercise Tool

This is a new tool, and is rife with bugs.  However, it appears to create
even more problems for device drivers and the kernel, so that's OK.

This tool generates large numbers of TCP connections and stuffs lots of data
into them.  One binary encapsulates both a client and a server.  Each of the
client and the server generates a certain number of worker processes, each of
which in turn uses its own TCP port.  The number of server processes must be
>= the number of client processes, or some of the ports required by the
client won't have a listener.  The client then proceeds to make connections 
and send data to the server.  Each worker multiplexes many connections at
once, up to a maximum parallelism limit.  The client can use one or many IP
addresses, in order to make more 4-tuples available for testing, and will
automatically spread the load of new connections across available source
addresses.

You will need to retune your TCP stack for high volume, see Configuration
Notes below.

The server has very little to configure, use the following command line
flags:

  -s                           Select server mode
  -p <numprocs>                Number of workers, should be >= client -p arg
  -r <baseport>                Non-default base TCP port, should match client
  -T                           Print CPU usage every ten seconds
  -m <maxconnectionsperproc>   Maximum simultaneous connections/proc, should
                               be >= client setting.

Typical use:

  ./tcpp -s -p 4 -m 1000000

This selects server mode, four workers, and at most 1 million TCP connections
per worker at a time.

The client has more to configure, with the following flags:

  -c <remoteIP>                Select client mode, and specific dest IP
  -C                           Print connections/second instead of GBps
  -M <localIPcount>            Number of sequential local IPs to use; req. -l
  -T                           Include CPU use summary in stats at end of run
  -b <bytespertcp>             Data bytes per connection
  -l <localIPbase>             Starting local IP address to bind
  -m <maxtcpsatonce>           Max simultaneous conn/worker (see server -m)
  -p <numprocs>                Number of workers, should be <= server -p
  -r <baseport>                Non-default base TCP port, should match server
  -t <tcpsperproc>             How many connections to use per worker
  
Typical use:

  ./tcpp -c 192.168.100.201 -p 4 -t 100000 -m 10000 -b 100000 \
    -l 192.168.100.101 -M 4

This creates four workers, each of which will (over its lifetime) set up and
use 100,000 TCP connections carrying 100K of data, up to 10,000 simultaneous
connection at any given moment.  tcpp will use four source IP addresses,
starting with 192.168.100.101, and all connections will be to the single
destination IP of 192.168.100.201.

Having (p) <= the number of cores is advisable.  When multiple IPs are used
on the client, they will be sequential starting with the localIPbase set with
-l.

Known Issues
------------

The bandwidth estimate doesn't handle failures well.  It also has serious
rounding errors and probably conceptual problems.

It's not clear that kevent() is "fair" to multiple connections.

Rather than passing the length for each connection, we might want to pass
it once with a control connection up front.  On the other hand, the server
is quite dumb right now, so we could take advantage of this to do size
mixes.

Configuration Notes
-------------------

In my testing, I use sysctl.conf entries of:

net.inet.ip.portrange.first=100
kern.ipc.maxsockets=1000000
net.inet.tcp.maxtcptw=3000000
kern.ipc.somaxconn=49152

# For running !multiq, do this before loading the driver:
kenv hw.cxgb.singleq="1"

kldload if_cxgb

# Consider turning off TSO and/or adjusting the MTU for some scenarios:
ifconfig cxgb0 -tso
ifconfig cxgb0 mtu 1500


$FreeBSD: releng/8.4/tools/tools/netrate/tcpp/README 189623 2009-03-10 14:52:17Z rwatson $
@


1.3
log
@SVN rev 209428 on 2010-06-22 10:45:35Z by rwatson

Revised tuning advice for tcpp benchmarking: do it in loader.conf, and
tweak more TCP/stack parameters.

Sponsored by:	Juniper Networks
MFC after:	1 week
@
text
@d108 1
a108 1
$FreeBSD$
@


1.3.2.1
log
@SVN rev 225736 on 2011-09-23 00:51:37Z by kensmith

Copy head to stable/9 as part of 9.0-RELEASE release cycle.

Approved by:	re (implicit)
@
text
@@


1.3.2.2
log
@## SVN ##
## SVN ## Exported commit - http://svnweb.freebsd.org/changeset/base/ 242902
## SVN ## CVS IS DEPRECATED: http://wiki.freebsd.org/CvsIsDeprecated
## SVN ##
## SVN ## ------------------------------------------------------------------------
## SVN ## r242902 | dteske | 2012-11-11 23:29:45 +0000 (Sun, 11 Nov 2012) | 10 lines
## SVN ##
## SVN ## Fix a regression introduced by SVN r211417 that saw the breakage of a feature
## SVN ## documented in usr.sbin/sysinstall/help/shortcuts.hlp (reproduced below):
## SVN ##
## SVN ## If /usr/sbin/sysinstall is linked to another filename, say
## SVN ## `/usr/local/bin/configPackages', then the basename will be used
## SVN ## as an implicit command name.
## SVN ##
## SVN ## Reviewed by:	adrian (co-mentor)
## SVN ## Approved by:	adrian (co-mentor)
## SVN ##
## SVN ## ------------------------------------------------------------------------
## SVN ##
@
text
@d108 1
a108 1
$FreeBSD: stable/9/tools/tools/netrate/tcpp/README 209428 2010-06-22 10:45:35Z rwatson $
@


1.3.2.1.4.1
log
@SVN rev 239080 on 2012-08-05 23:54:33Z by kensmith

Copy stable/9 to releng/9.1 as part of the 9.1-RELEASE release process.

Approved by:	re (implicit)
@
text
@@


1.3.2.1.4.2
log
@Switch importer
@
text
@d108 1
a108 1
$FreeBSD: releng/9.1/tools/tools/netrate/tcpp/README 209428 2010-06-22 10:45:35Z rwatson $
@


1.3.2.1.2.1
log
@SVN rev 227445 on 2011-11-11 04:20:22Z by kensmith

Copy stable/9 to releng/9.0 as part of the FreeBSD 9.0-RELEASE release
cycle.

Approved by:	re (implicit)
@
text
@@


1.3.2.1.2.2
log
@Switch importer
@
text
@d108 1
a108 1
$FreeBSD: releng/9.0/tools/tools/netrate/tcpp/README 209428 2010-06-22 10:45:35Z rwatson $
@


1.2
log
@SVN rev 208859 on 2010-06-05 22:59:37Z by rwatson

Although we currently don't compile in CPU-pinning support by default,
add a -P to enable it if it were.

MFC after:	1 week
Sponsored by:	Juniper Networks
@
text
@d83 1
a83 1
In my testing, I use sysctl.conf entries of:
a84 1
net.inet.ip.portrange.first=100
d88 9
@


1.1
log
@SVN rev 189623 on 2009-03-10 14:52:17Z by rwatson

Add tcpp -- TCP parallelism microbenchmark.

This tool creates large numbers of TCP connections, each of which will
transmit a fixed amount of data, between client and server hosts.  tcpp can
use multiple workers (typically up to the number of hardware cores), and can
use multiple source IPs in order to use an expanded port/IP 4-tuple space to
avoid problems from reusing 4-tuples too quickly.  Aggregate bandwidth use
will be reported after a client run.

While by no means a perfect tool, it has proven quite useful in generating
and optimizing TCP stack lock contention by easily generating high-intensity
workloads.  It also proves surprisingly good at finding device driver bugs.
@
text
@d42 1
@


1.1.2.1
log
@SVN rev 196045 on 2009-08-03 08:13:06Z by kensmith

Copy head to stable/8 as part of 8.0 Release cycle.

Approved by:	re (Implicit)
@
text
@@


1.1.2.2
log
@## SVN ##
## SVN ## Exported commit - http://svnweb.freebsd.org/changeset/base/ 242909
## SVN ## CVS IS DEPRECATED: http://wiki.freebsd.org/CvsIsDeprecated
## SVN ##
## SVN ## ------------------------------------------------------------------------
## SVN ## r242909 | dim | 2012-11-12 07:47:19 +0000 (Mon, 12 Nov 2012) | 20 lines
## SVN ##
## SVN ## MFC r242625:
## SVN ##
## SVN ## Remove duplicate const specifiers in many drivers (I hope I got all of
## SVN ## them, please let me know if not).  Most of these are of the form:
## SVN ##
## SVN ## static const struct bzzt_type {
## SVN ##       [...list of members...]
## SVN ## } const bzzt_devs[] = {
## SVN ##       [...list of initializers...]
## SVN ## };
## SVN ##
## SVN ## The second const is unnecessary, as arrays cannot be modified anyway,
## SVN ## and if the elements are const, the whole thing is const automatically
## SVN ## (e.g. it is placed in .rodata).
## SVN ##
## SVN ## I have verified this does not change the binary output of a full kernel
## SVN ## build (except for build timestamps embedded in the object files).
## SVN ##
## SVN ## Reviewed by:	yongari, marius
## SVN ##
## SVN ## ------------------------------------------------------------------------
## SVN ##
@
text
@d99 1
a99 1
$FreeBSD: stable/8/tools/tools/netrate/tcpp/README 189623 2009-03-10 14:52:17Z rwatson $
@


1.1.2.1.8.1
log
@SVN rev 232438 on 2012-03-03 06:15:13Z by kensmith

Copy stable/8 to releng/8.3 as part of 8.3-RELEASE release cycle.

Approved by:	re (implicit)
@
text
@@


1.1.2.1.8.2
log
@Switch importer
@
text
@d99 1
a99 1
$FreeBSD: releng/8.3/tools/tools/netrate/tcpp/README 189623 2009-03-10 14:52:17Z rwatson $
@


1.1.2.1.6.1
log
@SVN rev 216617 on 2010-12-21 17:09:25Z by kensmith

Copy stable/8 to releng/8.2 in preparation for FreeBSD-8.2 release.

Approved by:	re (implicit)
@
text
@@


1.1.2.1.4.1
log
@SVN rev 209145 on 2010-06-14 02:09:06Z by kensmith

Copy stable/8 to releng/8.1 in preparation for 8.1-RC1.

Approved by:	re (implicit)
@
text
@@


1.1.2.1.2.1
log
@SVN rev 198460 on 2009-10-25 01:10:29Z by kensmith

Copy stable/8 to releng/8.0 as part of 8.0-RELEASE release procedure.

Approved by:	re (implicit)
@
text
@@


