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:Server:# 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
# 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.