Page 1 of 1

Is the Windows client simply slower?

Posted: Tue Dec 13, 2011 3:25 pm
by leeph
OK, so I have a Debian Squeeze box running as firewall and VPN terminator on an ADSL line with 6mbit down and 1mbit upstream.

On a remote network, with a 20mbit synchronous internet connection, I have two boxes, one Windows 7, and one Debian Squeeze. I have configured the OpenVPN client on both machines and can access remote resources behind the OpenVPN server.

On the remote network side, I try pushing a file (whether it be using FTP, SCP, Windows file sharing) to a server behind the OpenVPN terminator, and my transfer rates from the Windows box are 66% slower than on the Linux machine. For example, I get transfer rates of about 650k/sec from Linux client, but only about 200k/sec on the Windows client, doing the exact same type of transfer.

Everything else is equal - the only difference is the fact that one machine is using the Linux client, and the other is Windows 7.

I've played about with MTU sizes, mssfix, nothing makes a difference - the fastest speeds for both clients occur without any tweaks at all.

Is the Windows Tun driver simply slower?

Client config below:

client
dev tun
proto udp
remote ***** 1194
resolv-retry infinite
nobind
persist-key
persist-tun
auth-nocache
ca ca.crt
cert cert.crt
key cert.key
tls-auth ta.key 1
comp-lzo
cipher AES-256-CBC

Cheers,

James / leeph

Re: Is the Windows client simply slower?

Posted: Wed Dec 14, 2011 8:28 am
by janjust
yes, the windows tun driver is quite a bit slower than the Linux one; also , for comparison purposes, try using the BF-CBC cipher: it could also be that your CPU has support for the AESNI instructions. The Linux version of OpenVPN (or rather, OpenSSL) can make use of this, the Windows version won't; by comparing the BF-CBC performance you can rule this out.

Re: Is the Windows client simply slower?

Posted: Wed Dec 14, 2011 11:20 am
by leeph
Thanks for the reply. I've just tried the BF-CBC cipher but speeds remain the same on the
Windows box.

It's good to know there is a known performance issue with the TUN driver. Does the same
apply to the TAP driver?

Last question I suppose would be, are there any plans that you're aware of to replace/upgrade
the TUN driver so that it performs to a similar high level as the Linux driver?

Cheers

James / leeph

Re: Is the Windows client simply slower?

Posted: Wed Dec 14, 2011 11:25 am
by janjust
It's good to know there is a known performance issue with the TUN driver. Does the same
apply to the TAP driver?
I wouldn't expect a major difference, but it depends a lot on the network layout (which should/could be remediated using mssfix/fragment etc).
Last question I suppose would be, are there any plans that you're aware of to replace/upgrade
the TUN driver so that it performs to a similar high level as the Linux driver?
not that I am aware of - the Windows tap-win32 driver needs to interface with the closed source Windows OS and will hence be harder to maintain than the fully open source Linux tun network driver+stack.

Re: Is the Windows client simply slower?

Posted: Wed Dec 14, 2011 1:40 pm
by janjust
As a followup: I just ran an 'iperf' test from my laptop to an OpenVPN 2.2.1 server, under both Fedora 14 64bit and Windows 7 Pro 64bit.
The laptop is connected to the server via a set of 100 Mbps switches. The client was running OpenVPN 2.2.1 in both cases as well.

Linux:
raw iperf: 94 Mbps
openvpn iperf: 90 Mbps

Windows 7:
raw iperf: 94 Mbps
openvpn iperf: 80 Mbps

so there is a larger performance drop when running OpenVPN on windows, but it's in the order of 10-12%.