Subject: IPsec performance
To: None <tech-security@netbsd.org, tech-net@netbsd.org,>
From: Thor Lancelot Simon <tls@rek.tjls.com>
List: tech-kern
Date: 07/18/2000 12:57:01
With 466MHz Celeron CPUs and decent network hardware (3c905B) the most
throughput I seem to be able to force through our IPsec is about 1.5MB/sec
(that's mega *bytes*, not bits).  Though I'm told by several people that
this is not atypical for a software-only IPsec implementation, I don't
understand _why_.

I am using ESP only, with blowfish-CBC and no message digest.  The
"bfspeed" test program from the OpenSSL library, with the library's
blowfish compiled to *not* use any of the asm or funky compiler flags
(that is, pretty much the exact code that's in the kernel's blowfish,
compiled with the same flags) can do 9.18 MB/sec in CBC mode on this
exact same hardware.

I don't understand where the 6X difference in performance is coming
from.  I would suspect cache effects but I think we're actually spending
most our time *not* encrypting -- if it were just that the cipher ran
much slower because the cache were being thrashed, I wouldn't expect
the machine to be spending most of its time in the idle loop, which it is;
I'd expect a huge increase in "sys" time during an IPsec transfer.

Interestingly, it's *also* not some kind of lockstep with the receiver;
two streams run as slowly as one.

Yes, I can buy a hardware crypto card and port the OpenBSD drivers.  But
given the actual cipher performance, I don't see why I should expect any
improvement.  Has anyone got an idea what's going on here?

-- 
Thor Lancelot Simon	                                      tls@rek.tjls.com
	"And where do all these highways go, now that we are free?"