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

Re: [Openvpn-users] LJ's "cons" of OpenVPN: how serious is latency?

  • Subject: Re: [Openvpn-users] LJ's "cons" of OpenVPN: how serious is latency?
  • From: James Yonan <jim@xxxxxxxxx>
  • Date: Tue, 21 Dec 2004 19:23:22 -0700 (MST)

On Tue, 21 Dec 2004, Florin Andrei wrote:

> On Tue, 2004-12-21 at 13:48 -0800, J. Perkins wrote:
> > http://www.linuxjournal.com/article/7949
> > I'm just wondering how important these considerations are in practice.
> > When
> > somebody says OpenVPN is "relatively slow", is that "slow" in an
> > academic, computer-science inefficient inter-process communication sort
> > of way, or slow in a my-users-will-complain sort of way? (And what
> > "fast" VPN method are we comparing this to, anyway? IPSec?)
> The former.
> See today's article on Slashdot about WiFi and PPTP - there's a guy
> commenting that he tried to setup an IPSec VPN (was it OpenSWAN? i don't
> remember) and he couldn't descend below 150ms latency - definitely not
> enough to play some network games.
> With OpenVPN he got 50ms which is more than enough for pretty much all
> applications.
> The implementation matters a lot, not just the design. OpenVPN seems to
> have an excellent implementation. I'm not judging from a code analysis
> standpoint, but from a plain user's.
> > Judging by the raves OpenVPN gets on this list for both performance and
> > reliability, I wonder how big a deal this is. I considered the LJ
> > writer might be over-stating the case
> He's overstating.
> The only serious defficiency of OpenVPN is that there is no "enterprise"
> class solution based on it, so large companies may not consider it.
> Otherwise, it's better than most IPSec-based VPNs on pretty much any
> account.
> > In a related note, would there be any benefit to using a WRAP w/a VPN
> > Mini-PCI card for crypto help? Again, I'm going to be limited in
> > throughput by the cable connections, so latency is my only concern.
> My OpenVPN server is an AthlonXP 1900. My typical client is a 2.6GHz
> Pentium M laptop. Even at full-speed transfer of large files over
> 802.11g, even with compression turned on at all times (non-adaptive
> compression), the CPUs barely blink, and the latency does not seem to be
> bigger than without VPN (i didn't do benchmarks, but it seems pretty
> fast).
> I've heard about people running VoIP over OpenVPN - that's the mother of
> all latency-sensitive applications. They say it works very well.

I've also run videoconferencing apps with no problem.

The one issue I was initially worried about was the TLS negotiation
latency.  On 1024 bit RSA keys running on a 2GHZ server, the latency hit
is about 40 milliseconds.  Generally with VoIP or videoconferencing, there
needs to be an audio "jitter" buffer of at least 150 or 200 milliseconds
to deal with random latencies in the link, so in most cases 40
milliseconds of OpenVPN-introduced latency once per hour per client isn't
even going to be noticed.

The latency is going to be most noticable when using 2048 bit RSA keys on
slower hardware.  One solution would be to use multithreading as in 1.x,
though at a certain level this seems like overkill.  While I do respect
the coolness factor of multithreading, the pragmatist in me sees it as
a devil's bargain of sorts where you trade stability for performance.

Another possible solution which needs more study to determine if it's 
feasible would be to process the TLS negotiation in smaller chunks, i.e. 
instead of calling BIO_read (in OpenSSL) and locking up the CPU for 40 
milliseconds, figure out a way that OpenSSL could process the TLS 
negotiation in, say, 10 milliseconds chunks, returning to OpenVPN after 
each chunk to allow another iteration through the event loop.  This would 
fix the latency problem while still maintaining OpenVPN's minimalistic 
single-thread execution model.


Openvpn-users mailing list