[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: how to tell if I getting anything out of my hifn1411 card
- To: misc_(_at_)_openbsd_(_dot_)_org
- Subject: Re: how to tell if I getting anything out of my hifn1411 card
- From: jared r r spiegel <jrrs_(_at_)_ice-nine_(_dot_)_org>
- Date: Thu, 13 Oct 2005 18:49:57 -0600
- Mail-followup-to: jared r r spiegel <jrrs_(_at_)_ice-nine_(_dot_)_org>, misc_(_at_)_openbsd_(_dot_)_org
On Thu, Oct 13, 2005 at 04:07:00PM -0600, Theo de Raadt wrote:
> > Even though the card is detected, I'm not seeing any boost in
> > IPsec performance.
> > Cpu is a Geode1100 - doing 10Mb/s IPsec has it maxed out :)
> The cpu is unable to feed the crypto card fast enough.
> You would think that doing crypto operations, especially 3DES
> is a lot of work. And it is. But there is a nearly fixed
> overhead for in the driver for managing the card.
> And it is a high overhead.
friend of mine and i tried setting up a 4501 as a router
doing IPsec for any wirelessly connected hosts ( WAPs on
the ethernets ).
we found the 4501 getting slaughtered by doing IPsec itself
( throughput from wireless to wired host, having gone
through the 4501, was down from ~1.2MB/s clear to ~180KB/s
with IPsec ), and then found that a 4501 + a 1411 really
ain't that much to write home about either. ( don't remember
precisely what it went up to with the 1411, maybe about
20%-30% of the way between CPU_IPsec and cleartext speeds ).
did some testing on a 4801 ( which your numbers seem to
indicate as being what you are doing it on too ) and
saw things pretty close to what you saw, +/- 1.5 Mb/s here
of note was that the type of crypto we were doing
( so long as it was supported by the hifn ) didn't matter
at all. we got essentially same throughput ( eg within
less than a megabit ) if we did 3des-cbc/MD5 or aes-128-cbc/MD5
or aes-256-cbc/SHA., etc
as a sidenote, i've also put a 1401 in a dual athlon.mp 2.14GHz
and seen openssl speed crank out a 20% or more improvement
in the 8k blocksize column, as compared to straight CPU.
( the hifn eats it compared to straight CPU for the lower 3
blocksizes, 4th one is sometimes either/or, depends on how much
-multi i am testing ).
in other words, the problem ain't the hifn, nor would your
situation be made better by a faster crypto chip; again,
the athlon.mp machine got beat at 8k blocksize with a hifn
it's easy to be an armchair quarterback, and perhaps i don't
know the whole story, but it'd be nice if soren-et-al. appeared
to not be resting on the laurels of selling a boat load of
4501/4801s over the past few years and instead was pumping
out some hardware that was fast enough to not suck for use
as something like a LAN<->LAN IPsec'd wireless router/AP.
[ openbsd 3.8 GENERIC ( sep 27 ) // i386 ]