[TriLUG] PoPToP VPN performance

[Jon Carnes]

On Wed, 2004-02-18 at 12:44, Ryan Wheaton wrote:
> Hey guys.
> 
> I did some testing last night, comparing file transfer speeds using 
> different protocols, with and without the VPN.  I used the same 19.1 MB 
> file do do each transfer.  Here's what I found:
> 
> With the VPN:
> 
> UPLOADING 	|	to windows file share, took about 13 minutes.
> 			|	using scp (secure copy) to a linux server, took about 10 minutes
> 
> DOWNLOADING	|	Using a browser (HTTP), got about 180Kb/sec transfer 
> rate, took about 2 min 15 sec
> 				|	using wget (HTTP), got about 135.80Kb/sec transfer rate, took 2 
> min 50 sec
> 				|	from windows file share (SMB), took about 9 minutes
> 				|	using scp from a linux server, took 2 min 13 sec
> 
> With out VPN:
> 
> UPLOADING	|	using scp to a linux server, took about 10 minutes
> 
> DOWNLOADING	|	using wget (HTTP) got 171Kb/s, took about 2 min 30 sec
> 				|	using a browser (HTTP) got 171.9 Kb/s took 1 min 53 sec
> 				|	using scp took 1 min 55 sec
> 
> 
> and they seem to be comparable.  My biggest problem, and the thing that 
> affects my users the most, is the sloooooow copy speed both up and down 
> copying to windows file shares.  Any suggestions on how I can track 
> down the bottleneck here or to improve performance?  I've got the WINS 
> server set in my options.pptpd file...  should I remove this?  Is there 
> any special routing that I can set up that will improve copy speeds?
> 
> thanks again for all the help before (and presently).
> 
> -rtw

Really interesting results!  Thanks for sharing those with us.

Ryan, most Windows boxes are set to respond to a local network so they
do terribly over a vpn.  You can modify a few parameters inside windows
and more than double your speed.  As I recall from days long ago there
is a registry parameter that controls the size of the "window" of sent
packets.  This is the amount of data that the box will send before it
requires a response back from the receiving server that indicates that
the earlier packets it sent got there.

If this window is filled up while waiting for return responses that the
earlier packets got there, then your computer is in fact NOT sending or
buffering any new packets at that time. 

Dslreports used to have a tool that let you measure this windows and
adjust it in the Windows Registry.
  http://www.dslreports.com/tools

I hope that is helpful! Good Luck - Jon Carnes