[netperf-talk] VPN throughput

Rick Jones rick.jones2 at hp.com
Tue Sep 2 10:12:41 PDT 2008


[The original posting got held-up for moderation - I cannot recall if it 
  was simple size or the HTML table.  For simple tables of numbers, 
simple ASCII is probably best. Anyhow, here it is. ]

Yash Khanduri wrote:
> While running the TCP_CRR test through VPN tunnel, I got very 
> inconsistent results as compare to without VPN setup:
> 
> *Local/Remote Socket Send bytes* 	*Local/Remote Socket Receive bytes* 
> *Request Size bytes* 	*Response Size bytes* 	*Elapsed Time Seconds* 
> *Transaction rate per second*
> 16384 	87380 	64 	64 	60 	163.68
> 16384 	87380 	  	  	  	 
> 16384 	87380 	128 	128 	60 	129.88
> 16384 	87380 	  	  	  	 
> 16384 	87380 	512 	512 	60 	117.46
> 16384 	87380 	  	  	  	 
> 16384 	87380 	1024 	1024 	60 	105.57
> 16384 	87380 	  	  	  	 
> 16384 	87380 	1400 	1400 	60 	315.73
> 16384 	87380 	  	  	  	 
> 16384 	87380 	1500 	1500 	60 	10.64
> 16384 	87380 	  	  	  	 
> 16384 	87380 	1600 	1600 	60 	292.7
> 16384 	87380 	  	  	  	 
> 16384 	87380 	1700 	1700 	60 	276.27
> 16384 	87380 	  	  	  	 
> 16384 	87380 	1800 	1800 	60 	228.78
> 16384 	87380 	  	  	  	 
> 16384 	87380 	1900 	1900 	60 	40.87
> 16384 	87380 	  	  	  	 
> 16384 	87380 	2000 	2000 	60 	65.72
> 16384 	87380 	  	  	  	 
> 16384 	87380 	5000 	5000 	60 	164.9
> 16384 	87380 	  	  	  	 
> 16384 	87380 	10000 	10000 	60 	104.33
> 16384 	87380 	  	  	  	 
> 
>  
> 
> Please tell me why the Transactions/second values are not showing higher 
> values for short message size and decreasing as the message size is 
> increasing.

What are the numbers for without the VPN?

Keep in mind that a TCP_CRR test is the exchange of six or more TCP 
segments:

   Netperf                   Netserver
     SYN             -->
                    <--        SYN|ACK
     ACK             -->
     Req             -->
                     <--       Rsp|ACK
     FIN             -->
                     <--       ACK|FIN
     ACK             -->

I'm ass-u-me-ing the ACK of the request will be piggy-backed on the Rsp 
and that the ACK of the netperf side's FIN will be piggy-backed on the 
netserver side's FIN.  A packet trace could confirm/refute that.

I would probably run a "plain" TCP_RR test with those request/response 
sizes and see what they look like, and then consider taking a packet 
trace of the VPN version.

Also, given the "issues" surrounding attempts to reuse connections in 
TIME_WAIT, it might be best to make sure that there is at least a 
"lengthof(TIME_WAIT) pause between TCP_CRR test instances.

happy benchmarking,

rick jones


More information about the netperf-talk mailing list