Date: Mon, 12 Apr 2004 11:45:36 -0600 From: Tillman Hodgson <tillman@seekingfire.com> To: FreeBSD Questions <freebsd-questions@freebsd.org> Subject: IPsec performance impact [was: Re: OS X and FreeBSD: What could be a good setup] Message-ID: <20040412174536.GB56037@seekingfire.com> In-Reply-To: <20040412143042.GA67287@happy-idiot-talk.infracaninophile.co.uk> References: <E6F31F15-8954-11D8-A222-000A956D2452@chrononomicon.com> <20040412143042.GA67287@happy-idiot-talk.infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 12, 2004 at 03:30:42PM +0100, Matthew Seaman wrote: > If you're that worried about WEP not being secure enough, you could > wrap the NFS connections in ipsec instead. It might have a bit of a > performance impact though. I'm a big fan of running IPsec over wireless connections. But I was shocked but the performance impact IPsec has. I collected some numbers netperf recently, shown below. Notes: * Athena (the household server) is a Celeron 900 wiith 256MB of RAM and a 'bge' gigE NIC running -STABLE * Caliban is a UltraSPARC 360 with 384MB of RAM and a 4-port 'hme' NIC running -CURRENT * Coyote is a Celeron 400 with 128MB of RAM and a 'rl' NIC * In my case racoon sets up 3des for me -- note that this isn't a CPU friendly scheme, though it is very likely to be compatible with other platforms * I run a seperate VLAN for IPsec traffic, so all IPsec traffic numbers include an assumed that they were also VLAN'ed * The IPsec'd IP of a host has it's own name in DNS, simply it's regular name prefixed with "sec". * I ran netserver (from netperf) on Athena and tested it for UDP_STREAM (a nice NFS-like test) over both the IPsec VLAN and the regular unencrypted link (non-VLAN'ed) Results: [root@caliban /usr/local/netperf]# ./netperf -t UDP_STREAM -H secathena Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 9216 9216 10.01 715 0 5.27 42080 10.01 713 5.25 [root@caliban /usr/local/netperf]# ./netperf -t UDP_STREAM -H athena Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 9216 9216 10.01 13004 13160 95.81 42080 10.01 12778 94.14 [root@coyote /usr/local/netperf]# ./netperf -t UDP_STREAM -H athen Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 9216 9216 10.00 10452 0 77.02 42080 10.00 10452 77.02 [root@coyote /usr/local/netperf]# ./netperf -t UDP_STREAM -H secathena Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 9216 9216 10.00 1789 0 13.18 42080 10.00 1789 13.18 During the tests the clients were CPU-bound. To put it bluntly, the performance impact is non-trivial. That's to be expected, and at the slower speeds of wireless networks it's more likely that more modern CPUs will be able to keep up. I wouldn't want to play a high-bitrate video file over an IPsec connection, though, as the video app and IPsec will starve each other of CPU cycles. -T -- The mere sense of living is joy enough. Emily Dickinson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040412174536.GB56037>