Subject: IPsec performance
To: None <,,>
From: Thor Lancelot Simon <>
List: tech-security
Date: 07/18/2000 12:57:01
  by with SMTP; 18 Jul 2000 16:58:36 -0000
	by (Postfix) with ESMTP
	id A6296156A2; Tue, 18 Jul 2000 12:57:01 -0400 (EDT)
Date: Tue, 18 Jul 2000 12:57:01 -0400
From: Thor Lancelot Simon <>
Subject: IPsec performance
Message-ID: <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i

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	                            
	"And where do all these highways go, now that we are free?"