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)
By Artem Teslenko (78.25.11.204) ates@ipv6.dp.ua on
Comments
By Anonymous Coward (217.197.149.135) on
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
By Anonymous Coward (81.83.46.237) on
> 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.
By Anonymous Coward (92.196.121.68) on
>
>
> 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.
By Anonymous Coward (59.167.252.29) on
>
>
> 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.
By Damien Miller (djm) on http://www.mindrot.org/~djm/
> 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.
By Anonymous Coward (74.59.190.33) on
Comments
By Damien Miller (djm) on http://www.mindrot.org/~djm/
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.