Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.

This page describes how to test the performance of DCCP, choosing suitable test applications, and how to
download the experimental DCCP test tree.
=====Contents=====

  * [[https://www.linuxfoundation.org/#TAHI_Conformance_Test_Suite|1 TAHI Conformance Test Suite]]
  * [[https://www.linuxfoundation.org/#Applications_suitable_for_DCCP_testing|2 Applications suitable for DCCP testing]]
    * [[https://www.linuxfoundation.org/#ttcp|2.1 ttcp]]
    * [[https://www.linuxfoundation.org/#iperf|2.2 iperf]]
    * [[https://www.linuxfoundation.org/#netsend|2.3 netsend]]
    * [[https://www.linuxfoundation.org/#Other_DCCP_source_code|2.4 Other DCCP source code]]
  * [[https://www.linuxfoundation.org/#Experimental_DCCP_source_tree|3 Experimental DCCP source tree]]
    * [[https://www.linuxfoundation.org/#How_to_obtain|3.1 How to obtain]]
      * [[https://www.linuxfoundation.org/#Cloning_the_entire_tree|3.1.1 Cloning the entire tree]]
      * [[https://www.linuxfoundation.org/#Faster_variant:_DCCP_subtree_only|3.1.2 Faster variant: DCCP subtree only]]
      * [[https://www.linuxfoundation.org/#Snapshots_.28single_patch_or_tarball.29|3.1.3 Snapshots (single patch or tarball)]]
    * [[https://www.linuxfoundation.org/#Regression_testing|3.2 Regression testing]]
      * [[https://www.linuxfoundation.org/#Results_for_CCID3|3.2.1 Results for CCID3]]
      * [[https://www.linuxfoundation.org/#Testing_with_constant_bitrate|3.2.2 Testing with constant bitrate]]
  * [[https://www.linuxfoundation.org/#Testbed_setup_for_DCCP|4 Testbed setup for DCCP]]
    * [[https://www.linuxfoundation.org/#Enabling_debugging_output|4.1 Enabling debugging output]]
    * [[https://www.linuxfoundation.org/#Setting_TX.2FRX_parameters|4.2 Setting TX/RX parameters]]
    * [[https://www.linuxfoundation.org/#Network_emulation_setup|4.3 Network emulation setup]]
    * [[https://www.linuxfoundation.org/#Monitoring_DCCP|4.4 Monitoring DCCP]]

======  TAHI Conformance Test Suite ======

For packet-level tests, please consider using the [[http://dccpct.sourceforge.net|DCCP Conformance Test Suite]].
======  Applications suitable for DCCP testing ======
==== ttcp====

There are currently 3 different variants of ttcp with DCCP support, the two latter ones are more recent. [[http://wand.net.nz/~iam4/dccp/ttcp_new.c|Here]] is a very early client which worked with earlier versions of DCCP. A more up-to-date implementation is the [[http://wand.net.nz/~iam4/dccp/ttcp_acme.c|`acme' variant]], which is based on code developed by Arnaldo de Melo. It has been updated to produce more verbose
output for TFRC (-v switch); it should be compiled like:
<code>gcc ttcp_acme.c -o ttcp_acme -I ~/linuxsrc/dccpwork/include/</code>

For comparison, the change to the original is in a different include:
<code>-#include <netinet/tfrc.h>
 // #include <netinet/tfrc.h>
 #include <linux/tfrc.h></code>

Here is a sample testing setup.

On receive end (10.0.2.2):
<code>ttcp -c -l256 -r</code>

\\ 
On send end (10.0.7.7):
<code>ttcp -c -l256 -n1000 -t 10.0.2.2</code>

The -l256 is used for the following reason: DCCP is a datagram-oriented protocol and works on fixed
datagram sizes (fragmentation is not supported and not likely to be in the near future). To avoid
sending datagrams larger than the path MTU, the datagram size must be set using the `-l' switch.

This is automated in the last version of ttcp, which automatically queries the path MTU and warns
before sending too large datagrams, or even adjusts outgoing datagram size. This variant can be downloaded[[http://www.erg.abdn.ac.uk/users/gerrit/dccp/apps/|here]]; it requires the MPS support from the DCCP test tree (see notes below).
==== iperf====

Alternatively [[:networking:iperf| Iperf ]] works better for many users.
==== netsend====

There is a third alternative: [[http://netsend.berlios.de/|netsend]]. It support nearly all DCCP options but isn't limited or focused on DCCP (e.g. support TCP-Lite, ...).
==== Other DCCP source code====

[[http://wand.net.nz/~iam4/dccp/dccp-cs-0.01.tar.bz2|Here]] is a simple client server application written using [[:networking:dccp| DCCP ]]. A number of current applications are listed on a [[http://www.erg.abdn.ac.uk/users/gerrit/dccp/apps/|DCCP applications page]]. Lastly, [[http://wand.net.nz/~iam4/dccp/sample/|here]] is sample code that uses the mmap interface for the 2.4 kernel - if people are interested in writing an mmap interface. It is no use trying it on Linux 2.6!!
======  Experimental DCCP source tree ======

Mainline kernel development takes a long time, even if changes are small, and DCCP is in some respects not a finished and fully tested protocol: to enable testing without the constraints of mainline development, a DCCP test tree has been set up.

This tree has features which are more recent than the mainline DCCP implementation. It is based on the netdev subtree by David Miller and contains patches from the DCCP mailing list which have not
yet been integrated into the mainline kernel.

We encourage using this tree for tests and report suggestions and comments to the DCCP [[http://www.mail-archive.com/dccp@vger.kernel.org/|mailing list]].

The experimental tree itself is contained as a subtree named `origin/dccp' within a standard git tree.
The next two sections describe how to pull this.
=====  How to obtain =====
====  Cloning the entire tree ====

To clone the entire tree (master basis plus `dccp' subtree), do the following:
<code> git-clone git://eden-feed.erg.abdn.ac.uk/dccp_exp my_dccp</code>

This will give you a basis in the directory `my_dccp'. If you have any sources already, then it is much better and faster to specify a reference repository with
the --reference argument - this significantly reduces download time. e.g:
<code> git-clone --reference mylinustree git://eden-feed.erg.abdn.ac.uk/dccp_exp my_dccp</code>

where mylinustree is the directory with Linus' tree and my_dccp is the new directory you wish to create.

You still need to check out the DCCP sub-branch, by creating a branch named `dccp' (or something else), which needs to be checked out like this:
<code> git-checkout --track -b dccp origin/dccp</code>

The `origin/dccp' is already in the sources you pulled, but you have to tell git to use it in a local branch.

However, as always, pulling entire [[https://www.linkedin.com/company/redgage-llc | source]] trees over the network takes a lot of bandwidth and time.
====  Faster variant: DCCP subtree only ====

If you already have fairly recent git Linux sources, then cloning the subtree is much much faster (the
differences amount to at most a few hundred KB). This variant is done from within your current Linux source tree.
First, create a new separate branch:
<code> git-checkout -b dccp master</code>

Now pull the experimental DCCP tree into this branch using
<code> git-pull git://eden-feed.erg.abdn.ac.uk/dccp_exp dccp</code>
====  Snapshots (single patch or tarball)====

If you don't want to set up git or find the above process too laborious, you can download

  *  snapshot patches for most recent kernel versions from [[http://www.erg.abdn.ac.uk/users/gerrit/dccp/testing_dccp/test-tree/|this directory]] (note: numbers are relative to git; if it does not apply cleanly on a www.kernel.org tree, try earlier version numbers, or report to dccp@vger),
  *  a [[http://eden-feed.erg.abdn.ac.uk/latest-dccp-test-tree.tar.bz2|nightly tarball of the DCCP test tree]] .
=====  Regression testing =====

If you make changes to [[:networking:dccp| DCCP ]] please test it by varying loss and delay as per above and compare the results to [[http://wand.net.nz/~perry/max_download.php|http://wand.net.nz/~perry/max_download.php]] - remember to change delayed acks from 2 to 1 or else the results are wrong.

Test this with [[:networking:iperf| Iperf ]] running for 60 seconds, with 1424 byte packets.
<code>iperf -d -l 1424 -c servername -p 5001 -t 60
iperf -d -l 1424 -s -p 5001</code>

Test with:

  *  10% loss and 150 millisecond delay
  *  1% loss and 40 millisecond delay

Try it on both CCID2 and CCID3. Instructions on changing CCID are found at the [[:networking:dccp| DCCP ]] page. Do at least 3 runs as results can vary a bit. Results don't need to exactly match as CCID3 is not exactly the same as TFRC and also the random loss can cause variation as can making losses in the same interval (which reduces loss rate, therefore higher throughput).

You should get close to line speed on two directly connected nodes or running with a router in between. NB There is an issue that Gerrit has identified [[http://www.erg.abdn.ac.uk/users/gerrit/dccp/notes/packet_scheduling/|here]]. You may also have an issue with CPU loading - check this when running also.
====  Results for CCID3 ====

Leaving queue length at its default (5)
^ Test ^ Desired ^ Test tree as at 23-Jun-07^
^ Direct connect CCID3| 100 Mbits | 92.6, 94.9, 94.9|
^ Routed CCID3| 100 Mbits | 94.9, 94.9, 94.9|
^ 10% loss, 150 ms RTT| 131 Kbits | 172, 199, 151|
^ 1% loss, 40 ms RTT| 3.05 Mbits | 3.28, 3.08, 3.03|
====  Testing with constant bitrate ====

The byte-blast mode of [[:networking:iperf| Iperf ]] can generate a lot of noise. In several test scenarios it is better to iteratively try higher bandwidths. The combined iperf patch has the -b switch which works in the same way as for UDP and enables CBR test runs. 
It requires that both the client (with an optional bandwidth specifier, e.g. `-b12m') and the server have CBR mode enabled. Further information can also be found [[http://www.erg.abdn.ac.uk/users/gerrit/dccp/apps/#iperf|here]].

This test mode is very useful for debugging and for running dccp_probe test runs (CBR generates less noise).
======  Testbed setup for DCCP ======

For a simple testbed setup, you can use two computers connected via a cross-over cable. However, adding one computer in between -- to emulate delay, loss, reordering -- gives you a much more realistic test setting (see notes on the use of netem below). In particular, if you are developing DCCP code, we encourage you to use this setting for the above regression testing.
=====  Enabling debugging output =====

The DCCP debugging output is fairly verbose and can give you good initial hints of what is going on. To enable debugging output, you need to both enable it in the kernel configuration and toggle the `debug' switch of the respective module. To avoid having to do this each time, you can place these into a file
underneath /etc/modutils.d or /etc/modprobe.d/ (see manpages for modules.conf and modprobe.conf), containing the following lines
<code> # options for DCCP
 options dccp            dccp_debug=1
 options dccp_ccid2      ccid2_debug=1
 options dccp_ccid3      ccid3_debug=1</code>
=====  Setting TX/RX parameters =====

See the [[:networking:dccp| DCCP ]] page for scripts to load the individual CCIDs.

There are a number of parameters that can (and should) be fine-tuned for testing. These all reside as read/write variables under
<code> /proc/sys/net/dccp/default</code>

These DCCP parameters are all described in Documentation/networking/dccp.txt. For example, to alter the TX queue length:
<code> echo $my_qlen > /proc/sys/net/dccp/default/tx_qlen</code>

Typically use a queue length of 5 if emulating UDP-like traffic and 16K/packet size if emulating TCP (this is default buffer size on a machine using 2.6.20).
=====  Network emulation setup =====

For more realistic testing, a separate box with at least two interfaces is used as a network emulator using the [[:networking:netem| Netem ]] kernel module. You can set the box up as router, but it is much simpler to configure it as a bridge and use the `tc' tool to set the traffic parameters. You will need the [[:networking:bridge| Netem ]] utilities (the page also has a description of [[http://crowdfund.co/raise-capital/ | how to]] set up bridging).

Here is how to turn loss with delay on:
<code>/sbin/tc qdisc add dev lan1 root netem delay $1ms loss $3%
/sbin/tc qdisc add dev lan0 root netem delay $1ms loss $2%</code>

and off:
<code>/sbin/tc qdisc del dev lan1 root netem
/sbin/tc qdisc del dev lan0 root netem</code>

And rate control with delay on:
<code>/sbin/tc qdisc add dev lan0 root handle 1:0 netem delay $1ms
/sbin/tc qdisc add dev lan1 root handle 1:0 netem delay $1ms
/sbin/tc qdisc add dev lan0 parent 1:1 handle 10: tbf rate $2kbit buffer 10000 limit 30000</code>

and off:
<code>/sbin/tc qdisc del dev lan0 parent 1:1
/sbin/tc qdisc del dev lan0 root
/sbin/tc qdisc del dev lan1 root</code>

As you can see you can use [[:networking:netem| Netem ]] to produce scenarios such as no delay, delay, loss, no loss.

NB In most versions of [[:networking:netem| Netem ]] except latest a minimum of 1/HZ delay is introduced per packet.
=====  Monitoring DCCP =====

DccpProbe is a good monitoring tool and helps you to debug. Its use is very much analogous to [[:networking:tcpprobe| TcpProbe ]], i.e. it is loaded as a module
<code>modprobe -v dccp_probe</code>

Then you start a process reading from /proc/net/dccpprobe
<code>cat /proc/net/dccpprobe >outfile & CAPTURE_PID=$!</code>

After running any kind of traffic tests, simply kill the process and read the file:
<code>iperf -d -c target-host -t 60; kill $CAPTURE_PID; less outfile</code>

More detailed information, as well as sample scripts to post-process the output from dccp_probe, can be found on [[http://www.erg.abdn.ac.uk/users/gerrit/dccp/testing_dccp/#dccp_probe|this page]].
Wiki

User Tools

Site Tools

Page Tools
