[dns-operations] wrapup of fragmentation/do/tcp discussion requested

[Rick Jones]

When I first read "120 connections per second" I thought it seemed 
rather trivial so I started seeing how I could (ab)use netperf to try to 
get an idea of the limits.  I had to make a couple of changes to the 
released 2.4.5 bits to make it work, but for a rough idea of the 
difference in protocol stack overhead between using UDP and TCP, one can 
probably take the _top_of_trunk_ netperf with a suvbersion client 
pointed at:

http://www.netperf.org/svn/netperf2/trunk

and then (ab)use the no-control connection option to run varations on 
the theme of:

manny:~# cat runem
netperf -H 192.168.1.100 -t TCP_CRR -c -C -l 30 -P 0 -- -r 128,4096 -P 
,12345 &
sleep 0.1
for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
do
   netperf -H 192.168.1.100 -t TCP_CRR -c -C -l 30 -N  -P 0 -- -r 
128,4096 -P ,12345 -L 192.168.1.$i &
done
manny:~# cat runem_udp
netperf -H 192.168.1.100 -t UDP_RR -c -C -l 30 -P 0 -- -r 128,4096 -P 
,12345 &
sleep 0.1
for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
do
   netperf -H 192.168.1.100 -t UDP_RR -c -C -l 30 -N  -P 0 -- -r 
128,4096 -P ,12345 -L 192.168.1.$i &
done

The idea being a "full control connection" test up and running, which 
will get the listen (in the case of TCP_CRR) endpoint going or the udp 
socket created in the case of UCP_RR).  The -N is the "no control 
connection" option.  The -P ,12345 sets the remote (server) port number 
and still lets netperf let the stack pick the local port number, the -L 
192.168.1.$1 is picking a different local (netperf side) IP address to 
help avoid TIME_WAIT conflicts.

One could also probably run one really long, but really slow 
(./configure --enable-intervals and then some global -b and -w options) 
first netperf command just to prime the pump and then run the real ones, 
either all from the same system or from different systems.

The server side of the UDP_RR test will be doing recvfrom()/sendto() by 
default.  The server side of the TCP_CRR test will be doing 
accept()/recv()/send()/close() - it started life behaving like an HTTP 
1.0 server might - one transaction per connection.

The -r option sets the request,response size, other help can be found 
either in the manual on netperf.org or emailing me.

The above will be single-threaded on the netserver side.  If you want to 
bring multiple cores into play on the netserver side, you can either add 
a -T ,N option to the "base" netperf command to bind netserver to some 
place other than the interrupt CPU, or you can run muliple "base" 
netperf commands with each using a different "server port number" - why 
not a different server IP - because IIRC I don't pass IP addresses in 
classic netperf control messages only port numbers.

FWIW a 1GbE link seems to max-out at around 29ishK trans/s with 4096 
byte responses.

happy benchmarking,

rick jones

PS - another way to run the UDP_RR side is to ./configure --enable-burst 
and then start incrementing a test-specific -b option to increase the 
number of transactions in flight between netperf and netserver for that 
test.  The TCP_CRR test cannot behave that way though, at least not as 
currently coded.  The TCP_RR test can (I would add a test-specific -D in 
that case) but that will have epsilon for the connection establishment 
overhead.