OpenBSD Journal

Welcome tcpbench(1) to base!

Contributed by sean on from the fill-my-pipe dept.

I noticed this morning a few commits of something called tcpbench(1) [man page not online as of this writing].

This is a new utility in -current and written by Damien Miller (djm@) to do synthetic TCP throughput benchmarking, similar in concept to tcpblast. The utility is used as both the client and server, whereas tcpblast required the discard service enabled in inetd on the server side.

What sets tcpbench(1) apart is it written to poll related kernel variables for more fine grained debugging and benchmarking!

As in many of the tools in base, it is really easy to setup. All you have to do is run tcpbench with the -s flag to start the server (default port is 12345) and connection is just as easy. To start the client just pass the IP of the server. The usual break (CTRL-C) stops the program from either side.

See below for an example of the default output:

Client:
# tcpbench 192.168.221.130
     pid   elapsed_ms          bytes         Mbps 
   28943         1015       20815984      164.067
   28943         2014       19533608      156.582
   28943         3003       15641592      126.653
   28943         4011       13691832      108.665
   28943         5003       17478416      141.097
   28943         6009       11573296       92.034
   28943         7003       18330744      147.680
tcpbench: Terminated by signal 2
Server:
# tcpbench -s    
     pid   elapsed_ms          bytes         Mbps   
   23324         1014       20748464      163.696   
   23324         2009       19357408      155.794   
   23324         3004       15834176      127.438   
   23324         4009       13562960      107.964   
   23324         5004       17576880      141.322   
   23324         6009       11592120       92.367   
   23324         7004       18361152      147.627   
   23324 closed by remote end  

There is a small number of knobs to fiddle with and since the man page hasn't hit the online repository yet here is the usage output:

Usage:
    tcpbench -l
    tcpbench [-v] [-p port] [-r rate] [host]
    tcpbench [-v] [-p port] [-r rate] -s
Options:
    -B buf       Set read/write buffer space (default: 262144)
    -h           Display this help
    -l           List kernel vars and exit
    -k var[,var] List of kernel PCB, TCB and socket variables to display
                 (requires read access to /dev/kmem)
    -p port      Specify port (default: 12345)
    -s           Server mode - listen for connections
                 (default: client mode - initiate connection)
    -r rate      Statistics display interval in milliseconds, or 0 to
                 disable (default: 1000)
    -S space     Set socket send/receive space (default: kernel default)
    -v           Increase verbosity

Now the interesting ability to print out kernel variables is the 'killer feature' for developers and while I have no idea what some of these mean, if you need them you'll probably know. I hope a description of them makes it to the man page (not as of yet).

Below is a listing of the available variables for your viewing pleasure:

Supported kernel variables:
        inpcb.inp_flags
        sockb.so_rcv.sb_cc
        sockb.so_rcv.sb_hiwat
        sockb.so_snd.sb_cc
        sockb.so_snd.sb_hiwat
        tcpcb.snd_una
        tcpcb.snd_nxt
        tcpcb.snd_wl1
        tcpcb.snd_wl2
        tcpcb.snd_wnd
        tcpcb.rcv_wnd
        tcpcb.rcv_nxt
        tcpcb.rcv_adv
        tcpcb.snd_max
        tcpcb.snd_cwnd
        tcpcb.snd_ssthresh
        tcpcb.t_rcvtime
        tcpcb.t_rtttime
        tcpcb.t_rtseq
        tcpcb.t_srtt
        tcpcb.t_rttvar
        tcpcb.t_rttmin
        tcpcb.max_sndwnd
        tcpcb.snd_scale
        tcpcb.rcv_scale
        tcpcb.last_ack_sent

From my understanding of the code the client allocates a buffer of random data, (by using arc4random_buf and just continually blasts it out the socket until you stop the application. Every 'rate' periods of time it spits out the current statistics.

This may not be the most exciting thing in the world, but it is nice to have something in base instead of having to come up with some kind of half-assed test every time I need one. The only thing I could hope for is the same application but using UDP but we'll see how this little tool progresses and maybe I'll even try tackling it myself.

(Comments are closed)


Comments
  1. By Artem Teslenko (78.25.11.204) ates@ipv6.dp.ua on

    Great! Very nice tool!

    Comments
    1. By Anonymous Coward (217.197.149.135) on

      > Great! Very nice tool!


      Well maybe it's a good tool but why to put it into base and why not to have it as a package only if somebody needs it? In my opinion in base should not be everything, it can bring potentional problems like for security etc.

      Comments
      1. By Anonymous Coward (81.83.46.237) on

        > why to put it into base and why not to have it as a package ...
        > in base should not be everything, it can bring potentional problems like for security etc.

        The packages and ports collection does NOT go through the same thorough security audit that is performed on the OpenBSD base system.

      2. By Anonymous Coward (92.196.121.68) on

        > > Great! Very nice tool!
        >
        >
        > Well maybe it's a good tool but why to put it into base and why not to have it as a package only if somebody needs it? In my opinion in base should not be everything, it can bring potentional problems like for security etc.
        >

        it is good to have one tool that is optimized and maintained for OpenBSD unlike the various tool in ports that have been developed for Linux. and a strong reason for tcpbench is that the developers are using this tool to work on TCP/IP and the network stack.

      3. By Anonymous Coward (59.167.252.29) on

        > > Great! Very nice tool!
        >
        >
        > Well maybe it's a good tool but why to put it into base and why not to have it as a package only if somebody needs it? In my opinion in base should not be everything, it can bring potentional problems like for security etc.

        What kind of security problem?

        If you have a situation where an untrusted person is able to maliciously execute potentially dangerous programs on your system, then you have already lost the security game. The loss came at the point where he was able to gain those privs.

      4. By Damien Miller (djm) on http://www.mindrot.org/~djm/

        > Well maybe it's a good tool but why to put it into base and why
        > not to have it as a package only if somebody needs it?

        It's in base because a few developers requested that it be there. At
        a binary size of ~20KB, I don't think it matters so much.

  2. By Anonymous Coward (74.59.190.33) on

    How does it compare to TTCP?

    Comments
    1. By Damien Miller (djm) on http://www.mindrot.org/~djm/

      > How does it compare to TTCP?

      Apart from the kvm(4) stuff in tcpbench(1) they are quite similar in function. I think the tcpbench(1) code is quite a bit cleaner, but ttcp supports at least one feature that tcpbench(1) doesn't support (yet): printing rusage.

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]