OpenVPN Hardware Requirements
I would guess an Atom CPU will handle 100mbit of OpenVPN traffic. Under load you might find an Atom will introduce a little more latency than a faster CPU but this will probably not be significant when considered against the latency of any long distant links you have between the server and the clients.
Some unscientific test results, running data between my netbook with an Atom CPU to a local OpenVPN server (over a 1000mbit network, but the netbook only has a 100Mbit NIC):
dspillett@minirant:~$ time dd if=/dev/zero bs=1024 count=1048576 | nc -q 0 192.168.43.1 3333
1048576+0 records in
1048576+0 records out
1073741824 bytes (1.1 GB) copied, 91.2072 s, 11.8 MB/s
real 1m31.227s
user 0m1.792s
sys 0m25.874s
dspillett@minirant:~$
dspillett@minirant:~$ time dd if=/dev/zero bs=1024 count=1048576 | nc -q 0 192.168.44.1 3333
1048576+0 records in
1048576+0 records out
1073741824 bytes (1.1 GB) copied, 113.082 s, 9.5 MB/s
real 1m53.107s
user 0m1.468s
sys 0m15.337s
dspillett@minirant:~$
where 192.168.43.1 is the server as seen just over the local network and 192.168.44.1 is the same machine as seen via an OpenVPN link over that network. The VPN is in bridged mode, using a UDP based connection.
htop showed the CPU being taxed more during the VPN test than the user+sys counts from time indicate because time is only counting dd's CPU activity not the VPN's. It showed cpu0 at ~70% and cpu1 at ~30% all through the test which would suggest the CPU is close to the limit it can transfer via OpenVPN in that test (that Atom was single core but with hyperthreading) - though it still managed to shuffle along at 9.5Mbyte/sec.
As an indication of the latency added by the VPN (which will be a combination of overheads from CPU work encrypting data and overhead from the tunnelling method), pinging with small (default, 56 byte payload) packets:
--- 192.168.43.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 8997ms
rtt min/avg/max/mdev = 0.138/0.166/0.183/0.015 ms
--- 192.168.44.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 8998ms
rtt min/avg/max/mdev = 0.544/0.614/0.860/0.091 ms
and larger (2048 byte payload) ones:
--- 192.168.43.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet los
rtt min/avg/max/mdev = 0.514/0.521/0.531/0.021 ms
--- 192.168.44.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9011ms
rtt min/avg/max/mdev = 0.710/0.997/1.437/0.173 ms
Obviously you'll get different results with the VPN handling multiple connections exhibiting real-world traffic patterns, so you might want to perform some more detailed tests yourself. You might be able to squeeze more out with some tweaking - my OpenVPN set is pretty much running on out-of-the box defaults.
I'm not aware of any published benchmarks other than some informal tests a few people have run and posted to their web sites. Anecdotally, the crypto code (OpenSSL) doesn't seem to be the most optimized in the world but it doesn't seem to be a pig either. An easy benchmark for you would be to setup an OpenVPN server and client on a couple PCs on a LAN and time moving some traffic across them while watching CPU load on both.
I can tell you that I'm able to saturate an 802.11g link operating at 54Mbps with encrypted traffic without max'ing out the CPU on a junk Pentium II 400Mhz machine that is the OpenVPN server on my home LAN. That makes me think that the Geode could probably do it, too.
OpenSSL (and therefore OpenVPN) supports some hardware offload solutions, too. A low-end solution is the Via "padlock", included in some Via chipsets. That might also be a way to keep your CPU requirements low. See:
- http://ubuntuforums.org/showthread.php?t=710243
- http://www.a110wiki.de/wiki/VIA_Padlock