Subject: IPsec performance
To: None <email@example.com, firstname.lastname@example.org,>
From: Thor Lancelot Simon <email@example.com>
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
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 firstname.lastname@example.org
"And where do all these highways go, now that we are free?"