[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Web openvpn.net

Re: [Openvpn-users] speed

  • Subject: Re: [Openvpn-users] speed
  • From: Timothy Madden <terminatorul@xxxxxxxxx>
  • Date: Sun, 26 Aug 2007 03:10:43 +0300

Mira Suk wrote:
>> Have you been careful enough when you took the transfer times ? To have 
>> no other
>> downloads in the background, like maybe Windows update ? Or maybe your
>> ISP allows high transfer rates to you for some time, after which it will 
>> impose your
>> traffic limit. Or maybe somewhere in between your endpoints the bandwith 
>> may vary.
>> To check if you get overhead measure bandwidth at the interface level. 
>> In Windows
>> look at Connection properties to see the number of bytes or packets 
>> transferred.
>> You will most likely see that the physical speed is also low when using 
>> VPN,
>> which would mean encryption takes too much time or you have a slow or
> busy
>> computer. Or maybe the other end is slow or busy.
> Well, openvpn service sits at 0% CPU usage all the time - and I'm almost sure server wasn't busy, at least task manager says so (system idle 10:38, uptime 10:41). 
> Internet connection was unused (that says Firewall - only PC accessing internet was server with openVPN), openVPN and FTP shows only me in logs for today) Windows Update is disabled on server, and I have faster connection than openVPN server.
> measuring traffic on interface is good idea but I don't believe it will change anything (maybe only if my PC decided to slow down two of three tests with the fastest one last) - but I will try. well I will probably measure on firewall for server.
> benching, benching...
> 	        down server	up server      up client  down client     time/sec
> FTP	        1547	     103851	    1820	 104006	      476 
> FTP through VPN	5761		107354		5360	   108216	  704
> time is better than was previously, maybe something really happened. 3.5x upload ? lots of ACKs I guess.
> ok, seeing this, first thing I thought about is my connection upload - 4096/256 - however this should not be case for me, but maybe for users (they still sell connections like 2048/128 here). 
> Also note that this behavior is not only for me - I don't use this VPN regularily (just for server maintenance) I just set it up for friend's company, users were the ones noticing this behaviour - "much" slower than FTP.
> Anyway just to be sure I run bench of my and server connection and I got 22KiB while upload during transfer was 7,6KiB and download 417KiB while transfer was 153KiB, server have 242/238KiB. OpenVPN CPU usage 0% (both ends, I E6600@xxx server Dual Core Xeon@xxx x 2). oh well.
Excellent stats !

Looks like OpenVPN only introduces overhead on the upload. Over all you 
have basically  no overhead.
Your download/upload ratio was almost 16:1, and a connection like 
2048/128 like you said means exactly 16:1
Your connection 4069/256 is also exactly 16:1.

This indicates that you are bound by your upload speed if you ask me :(

And I can not blame the encryption and encapsulation methods for 
introducing overhead on the reverse direction,
it is otherwise a good idea so that you have no overhead on the main 

This is exactly why I hate ADSL. Like consumer users must not be allowed 
to have some upload !

Especially when peer to peer download software (I use eMule) today trade 
download for upload.
Or maybe I just want to share music or some CD images with my friends. 
Today a photo camera can easily fill
two CDs with photos after a complete shooting session. How will I show 
the photos to my friends on the
internet if all I have is an ADSL connection ?

I for one have a bandwidth between 50/25 and 100/50 (kB/s) at home, with a
cable modem on a TV cable. I bought the line with 50/25, and my provider 
is trying to improve their service to
100/50, only they are not quite there yet.

Ok this is off-topic but I am just mad at what is happening.

I do not know what you could do to fix your problem. Maybe algorithms 
other than blowfish introduce overhead
on the main direction as opposed to overhead on the reverse direction. I 
don't know.

I also have some problems with UDP on my network card (but in my case it 
is because of a bug in the card's
hardware or driver). Maybe you can also try tcp-server/tcp-client 
instead of udp as protocol.

Hope that helps,
OpenVPN mailing lists