[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