Status of hardware encryption accelerators

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Status of hardware encryption accelerators

Bhima Pandava
I know this had been asked before but I did not see an answer nor did
I see an update on the relate OpenBSD web pages.

What is the status of hardware encryption accelerators?

I too have read the web pages and frankly they sound outdated or at
best old.  I have the impression that some years ago there was a big
push to include support for these devices and encryption in general
and once completed not much else has been done.

Is this the case?


Thanks
Bhima

Reply | Threaded
Open this post in threaded view
|

Re: Status of hardware encryption accelerators

Darrin Chandler
On Sat, Nov 04, 2006 at 02:34:45PM +0100, Bhima Pandava wrote:

> I know this had been asked before but I did not see an answer nor did
> I see an update on the relate OpenBSD web pages.
>
> What is the status of hardware encryption accelerators?
>
> I too have read the web pages and frankly they sound outdated or at
> best old.  I have the impression that some years ago there was a big
> push to include support for these devices and encryption in general
> and once completed not much else has been done.
>
> Is this the case?

I'm not using any crypto hardware but I'm mildly interested, so I've
read the messages over time.

For desktop/server use, hardware acceleration for crypto seems
increasingly irrelevant as processors become faster. Yawn.

For "appliances" such as soekris, WRAP, et al, crypto in hardware can
still be quite important. There seems to be some discussions on the
soekris community lists. I see the occasional post here about someone
trying to make sure their accelerator is being used in OpenBSD (if it's
detected then it'll get used).

If you have questions about a specific platform or application you'll
probably get more responses from people.

--
Darrin Chandler            |  Phoenix BSD Users Group
[hidden email]   |  http://bsd.phoenix.az.us/
http://www.stilyagin.com/  |

Reply | Threaded
Open this post in threaded view
|

Re: Status of hardware encryption accelerators

Bhima Pandava
Interesting.

I had assumed that hardware accelerators kept more or less the same
pace of improvement as general purpose CPUs.  Can you point to any
literature that shows that it doesn't?

On 11/4/06, Darrin Chandler <[hidden email]> wrote:

> On Sat, Nov 04, 2006 at 02:34:45PM +0100, Bhima Pandava wrote:
> > I know this had been asked before but I did not see an answer nor did
> > I see an update on the relate OpenBSD web pages.
> >
> > What is the status of hardware encryption accelerators?
> >
> > I too have read the web pages and frankly they sound outdated or at
> > best old.  I have the impression that some years ago there was a big
> > push to include support for these devices and encryption in general
> > and once completed not much else has been done.
> >
> > Is this the case?
>
> I'm not using any crypto hardware but I'm mildly interested, so I've
> read the messages over time.
>
> For desktop/server use, hardware acceleration for crypto seems
> increasingly irrelevant as processors become faster. Yawn.
>
> For "appliances" such as soekris, WRAP, et al, crypto in hardware can
> still be quite important. There seems to be some discussions on the
> soekris community lists. I see the occasional post here about someone
> trying to make sure their accelerator is being used in OpenBSD (if it's
> detected then it'll get used).
>
> If you have questions about a specific platform or application you'll
> probably get more responses from people.
>
> --
> Darrin Chandler            |  Phoenix BSD Users Group
> [hidden email]   |  http://bsd.phoenix.az.us/
> http://www.stilyagin.com/  |

Reply | Threaded
Open this post in threaded view
|

Re: Status of hardware encryption accelerators

Darrin Chandler
On Sat, Nov 04, 2006 at 03:44:07PM +0100, Bhima Pandava wrote:
> Interesting.
>
> I had assumed that hardware accelerators kept more or less the same
> pace of improvement as general purpose CPUs.  Can you point to any
> literature that shows that it doesn't?

No, my information is merely gleaned from reading mailing lists and I'm
not using hw acceleration. For all I know you may be right, and there
are very fast accelerators out there. My point is that for common tasks
any recent desktop/server hardware is fine. VPNing a few offices
together should not present a challenge to a modern processor, so adding
acceleration would be a waste.

If your demand is high, or your hardware is underpowered then that's
different.

--
Darrin Chandler            |  Phoenix BSD Users Group
[hidden email]   |  http://bsd.phoenix.az.us/
http://www.stilyagin.com/  |

Reply | Threaded
Open this post in threaded view
|

Re: Status of hardware encryption accelerators

Joachim Schipper
In reply to this post by Bhima Pandava
On Sat, Nov 04, 2006 at 02:34:45PM +0100, Bhima Pandava wrote:

> I know this had been asked before but I did not see an answer nor did
> I see an update on the relate OpenBSD web pages.
>
> What is the status of hardware encryption accelerators?
>
> I too have read the web pages and frankly they sound outdated or at
> best old.  I have the impression that some years ago there was a big
> push to include support for these devices and encryption in general
> and once completed not much else has been done.
>
> Is this the case?

IIRC, there is currently interest, or possibly even an effort, or it
might even be completed, into getting the crypto instructions working on
VIA C7; while not a separate crypto accelerator, this could fulfill
pretty much the same role.

                Joachim

Reply | Threaded
Open this post in threaded view
|

Re: Status of hardware encryption accelerators

Shane J Pearson
In reply to this post by Bhima Pandava
Bhima,

Quoting Bhima Pandava <[hidden email]>:

> Interesting.
>
> I had assumed that hardware accelerators kept more or less the same
> pace of improvement as general purpose CPUs.  Can you point to any
> literature that shows that it doesn't?

CPU's keep getting faster and crypto accelerators keep getting faster. But
from what I can tell, due to the bus between them, you can be taking two steps
forward and then one step back.

The amazing AES performance of the VIA CPU's seem to show a better way.


Shane



------------------------------------------------------------
This email was sent from Netspace Webmail: http://www.netspace.net.au

Reply | Threaded
Open this post in threaded view
|

Re: Status of hardware encryption accelerators

Greg Mortensen
In reply to this post by Darrin Chandler
Darrin Chandler <[hidden email]> wrote:

> For desktop/server use, hardware acceleration for crypto seems
> increasingly irrelevant as processors become faster. Yawn.

   From a VIA PadlockACE equipped SBC:

              16 bytes    64 bytes     256 bytes    1024 bytes   8192 bytes
aes-128-cbc  31885.24k   118568.67k   312349.58k   535048.83k   649099.91k

   From a "irrelevant as processors become faster" i386:

aes-128-cbc  61905.43k   83868.59k    91948.85k    93908.47k    93081.82k

   Yawn indeed.

> For "appliances" such as soekris, WRAP, et al, crypto in hardware can
> still be quite important.

   It is here that's it's quite irrelevant, as these little CPUs cannot
feed the accelerator fast enough.  From a vpn1411 equipped Soekris:

aes-128-cbc  63.65k      250.39k      944.13k     2953.46k     7989.79k

> I see the occasional post here about someone trying to make sure their
> accelerator is being used in OpenBSD ...

   ...because the userland -> kernel -> userland transition makes a
hardware accelerated Soekris slower than a stock one, except for large
block sizes.  From a net4801:

aes-128-cbc  2408.59k   2738.99k     2810.27k     2841.62k    2766.26k

   Regards,
     Greg

  \|/   ___   \|/    [hidden email]    +----- 2048R/38BD6CAB -----+
   @~./'O o`\.~@                            | 02BD EF81 91B3 1B33 64C2 |
  /__( \___/ )__\                           | 3247 6722 7006 38BD 6CAB |
     `\__`U_/'                              +--------------------------+

Reply | Threaded
Open this post in threaded view
|

Re: Status of hardware encryption accelerators

Darrin Chandler
On Sat, Nov 04, 2006 at 11:09:56PM -0500, Greg Mortensen wrote:

> Darrin Chandler <[hidden email]> wrote:
>
> >For desktop/server use, hardware acceleration for crypto seems
> >increasingly irrelevant as processors become faster. Yawn.
>
>   From a VIA PadlockACE equipped SBC:
>
>              16 bytes    64 bytes     256 bytes    1024 bytes   8192 bytes
> aes-128-cbc  31885.24k   118568.67k   312349.58k   535048.83k   649099.91k
>
>   From a "irrelevant as processors become faster" i386:
>
> aes-128-cbc  61905.43k   83868.59k    91948.85k    93908.47k    93081.82k
>
>   Yawn indeed.
>
> >For "appliances" such as soekris, WRAP, et al, crypto in hardware can
> >still be quite important.
>
>   It is here that's it's quite irrelevant, as these little CPUs cannot
> feed the accelerator fast enough.  From a vpn1411 equipped Soekris:
>
> aes-128-cbc  63.65k      250.39k      944.13k     2953.46k     7989.79k
>
> >I see the occasional post here about someone trying to make sure their
> >accelerator is being used in OpenBSD ...
>
>   ...because the userland -> kernel -> userland transition makes a
> hardware accelerated Soekris slower than a stock one, except for large
> block sizes.  From a net4801:
>
> aes-128-cbc  2408.59k   2738.99k     2810.27k     2841.62k    2766.26k

Thanks for posting some hard numbers! Very interesting and good to know.
Can you say what the "irrelevant" i386 machine is? Lots of difference
between a 90MHz PentiumI and a 3GHz Opteron, and I'd like to know where
those numbers fit in.

--
Darrin Chandler            |  Phoenix BSD Users Group
[hidden email]   |  http://bsd.phoenix.az.us/
http://www.stilyagin.com/  |

Reply | Threaded
Open this post in threaded view
|

Re: Status of hardware encryption accelerators

Greg Mortensen
On Sun, 5 Nov 2006, Darrin Chandler wrote:

> Can you say what the "irrelevant" i386 machine is? Lots of difference
> between a 90MHz PentiumI and a 3GHz Opteron, and I'd like to know where
> those numbers fit in.

   The i386 results were sent to me off-list, so I don't know the
processor details. "It's fast" will have to suffice.  To put it in
perspective, my fastest Intel systems report:

Xeon 3.00GHz
aes-128-cbc  56117.94k  59781.24k  62908.69k  63702.29k  63485.95k

Xeon 3.40GHz
aes-128-cbc  64935.33k  71725.72k  74294.15k  75431.37k  75419.89k

   Regards,
     Greg

  \|/   ___   \|/    [hidden email]    +----- 2048R/38BD6CAB -----+
   @~./'O o`\.~@                            | 02BD EF81 91B3 1B33 64C2 |
  /__( \___/ )__\                           | 3247 6722 7006 38BD 6CAB |
     `\__`U_/'                              +--------------------------+

Reply | Threaded
Open this post in threaded view
|

Re: Status of hardware encryption accelerators

Andy Hayward
In reply to this post by Darrin Chandler
Machine 1:
cpu0: AMD Athlon(TM) XP 2500+ ("AuthenticAMD" 686-class) 1.83 GHz

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc      27752.30k    30348.75k    31400.62k    31634.09k    31639.75k

Machine 2:
cpu0: AMD Athlon(TM) XP 2600+ ("AuthenticAMD" 686-class, 512KB L2
cache) 1.91 GHz
ubsec0 at pci0 dev 11 function 0 "Broadcom 5805" rev 0x01: 3DES MD5
SHA1 RNG PK, irq 3

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc      53267.77k    65862.29k    70738.31k    72143.81k    72609.77k

-- ach

Reply | Threaded
Open this post in threaded view
|

Re: Status of hardware encryption accelerators

Darrin Chandler
In reply to this post by Greg Mortensen
Greg Mortensen wrote:

> On Sun, 5 Nov 2006, Darrin Chandler wrote:
>
>> Can you say what the "irrelevant" i386 machine is? Lots of difference
>> between a 90MHz PentiumI and a 3GHz Opteron, and I'd like to know where
>> those numbers fit in.
>
>   The i386 results were sent to me off-list, so I don't know the
> processor details. "It's fast" will have to suffice.  To put it in
> perspective, my fastest Intel systems report:
>
> Xeon 3.00GHz
> aes-128-cbc  56117.94k  59781.24k  62908.69k  63702.29k  63485.95k
>
> Xeon 3.40GHz
> aes-128-cbc  64935.33k  71725.72k  74294.15k  75431.37k  75419.89k

My fastest:
cpu0: AMD Opteron(tm) Processor 246, 1994.63 MHz
cpu1: AMD Opteron(tm) Processor 246, 1994.32 MHz
type         16 bytes   64 bytes   256 bytes   1024 bytes   8192 bytes
aes-128-cbc  80713.16k  87876.85k   91431.72k    92622.31k    92688.52k

While that's *more* than fast enough for common tasks, the SBC + VIA
PadlockACE numbers you gave whip the pants off it for anything > 16 bytes.

--
Darrin Chandler            |  Phoenix BSD Users Group
[hidden email]   |  http://bsd.phoenix.az.us/
http://www.stilyagin.com/  |

Reply | Threaded
Open this post in threaded view
|

Re: Status of hardware encryption accelerators

Andreas Bihlmaier-2
On Mon, Nov 06, 2006 at 09:49:07AM -0700, Darrin Chandler wrote:

> Greg Mortensen wrote:
> >On Sun, 5 Nov 2006, Darrin Chandler wrote:
> >
> >>Can you say what the "irrelevant" i386 machine is? Lots of difference
> >>between a 90MHz PentiumI and a 3GHz Opteron, and I'd like to know where
> >>those numbers fit in.
> >
> >  The i386 results were sent to me off-list, so I don't know the
> >processor details. "It's fast" will have to suffice.  To put it in
> >perspective, my fastest Intel systems report:
> >
> >Xeon 3.00GHz
> >aes-128-cbc  56117.94k  59781.24k  62908.69k  63702.29k  63485.95k
> >
> >Xeon 3.40GHz
> >aes-128-cbc  64935.33k  71725.72k  74294.15k  75431.37k  75419.89k
>
> My fastest:
> cpu0: AMD Opteron(tm) Processor 246, 1994.63 MHz
> cpu1: AMD Opteron(tm) Processor 246, 1994.32 MHz
> type         16 bytes   64 bytes   256 bytes   1024 bytes   8192 bytes
> aes-128-cbc  80713.16k  87876.85k   91431.72k    92622.31k    92688.52k
>
> While that's *more* than fast enough for common tasks, the SBC + VIA
> PadlockACE numbers you gave whip the pants off it for anything > 16 bytes.

Well, you should also consider bytes/watt :)
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc      48246.54k   175071.41k   472434.09k   788228.58k   980033.81k

OpenBSD 4.0 (GENERIC) #1107: Sat Sep 16 19:15:58 MDT 2006
    [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: VIA Esther processor 1500MHz ("CentaurHauls" 686-class) 1.50 GHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,CMOV,PAT,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,SBF,SSE3,EST,TM2

Regards,
ahb

Reply | Threaded
Open this post in threaded view
|

Re: Status of hardware encryption accelerators - wetblanket

Dag Richards
Andreas Bihlmaier wrote:

> On Mon, Nov 06, 2006 at 09:49:07AM -0700, Darrin Chandler wrote:
>> Greg Mortensen wrote:
>>> On Sun, 5 Nov 2006, Darrin Chandler wrote:
>>>
>>>> Can you say what the "irrelevant" i386 machine is? Lots of difference
>>>> between a 90MHz PentiumI and a 3GHz Opteron, and I'd like to know where
>>>> those numbers fit in.
>>>  The i386 results were sent to me off-list, so I don't know the
>>> processor details. "It's fast" will have to suffice.  To put it in
>>> perspective, my fastest Intel systems report:
>>>
>>> Xeon 3.00GHz
>>> aes-128-cbc  56117.94k  59781.24k  62908.69k  63702.29k  63485.95k
>>>
>>> Xeon 3.40GHz
>>> aes-128-cbc  64935.33k  71725.72k  74294.15k  75431.37k  75419.89k
>> My fastest:
>> cpu0: AMD Opteron(tm) Processor 246, 1994.63 MHz
>> cpu1: AMD Opteron(tm) Processor 246, 1994.32 MHz
>> type         16 bytes   64 bytes   256 bytes   1024 bytes   8192 bytes
>> aes-128-cbc  80713.16k  87876.85k   91431.72k    92622.31k    92688.52k
>>
>> While that's *more* than fast enough for common tasks, the SBC + VIA
>> PadlockACE numbers you gave whip the pants off it for anything > 16 bytes.
>
> Well, you should also consider bytes/watt :)
> type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
> aes-128-cbc      48246.54k   175071.41k   472434.09k   788228.58k   980033.81k
>
> OpenBSD 4.0 (GENERIC) #1107: Sat Sep 16 19:15:58 MDT 2006
>     [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: VIA Esther processor 1500MHz ("CentaurHauls" 686-class) 1.50 GHz
> cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,CMOV,PAT,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,SBF,SSE3,EST,TM2
>
> Regards,
> ahb
>

Those are very impressive numbers.
What are you getting through these gateways?
What is the net usable throughput client PCs on either end are able to
exchange over the VPN?

Reply | Threaded
Open this post in threaded view
|

Re: Status of hardware encryption accelerators - wetblanket

Andreas Bihlmaier-2
On Mon, Nov 06, 2006 at 09:51:13AM -0800, Dag Richards wrote:

> Andreas Bihlmaier wrote:
> >On Mon, Nov 06, 2006 at 09:49:07AM -0700, Darrin Chandler wrote:
> >>Greg Mortensen wrote:
> >>>On Sun, 5 Nov 2006, Darrin Chandler wrote:
> >>>
> >>>>Can you say what the "irrelevant" i386 machine is? Lots of difference
> >>>>between a 90MHz PentiumI and a 3GHz Opteron, and I'd like to know where
> >>>>those numbers fit in.
> >>> The i386 results were sent to me off-list, so I don't know the
> >>>processor details. "It's fast" will have to suffice.  To put it in
> >>>perspective, my fastest Intel systems report:
> >>>
> >>>Xeon 3.00GHz
> >>>aes-128-cbc  56117.94k  59781.24k  62908.69k  63702.29k  63485.95k
> >>>
> >>>Xeon 3.40GHz
> >>>aes-128-cbc  64935.33k  71725.72k  74294.15k  75431.37k  75419.89k
> >>My fastest:
> >>cpu0: AMD Opteron(tm) Processor 246, 1994.63 MHz
> >>cpu1: AMD Opteron(tm) Processor 246, 1994.32 MHz
> >>type         16 bytes   64 bytes   256 bytes   1024 bytes   8192 bytes
> >>aes-128-cbc  80713.16k  87876.85k   91431.72k    92622.31k    92688.52k
> >>
> >>While that's *more* than fast enough for common tasks, the SBC + VIA
> >>PadlockACE numbers you gave whip the pants off it for anything > 16 bytes.
> >
> >Well, you should also consider bytes/watt :)
> >type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
> >bytes
> >aes-128-cbc      48246.54k   175071.41k   472434.09k   788228.58k  
> >980033.81k
> >
> >OpenBSD 4.0 (GENERIC) #1107: Sat Sep 16 19:15:58 MDT 2006
> >    [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC
> >cpu0: VIA Esther processor 1500MHz ("CentaurHauls" 686-class) 1.50 GHz
> >cpu0:
> >FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,CMOV,PAT,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,SBF,SSE3,EST,TM2
> >
> >Regards,
> >ahb
> >
>
> Those are very impressive numbers.
> What are you getting through these gateways?
> What is the net usable throughput client PCs on either end are able to
> exchange over the VPN?

This is just home usage, all over long 100mbit lines with dirty cheap
switches (several) in between.

#ipsec.conf (extract):
#------------------------------- Makros ---------------------------------------#
quick_enc = "aes"
quick_auth = "hmac-md5" # <- sha is much more expensive
ike esp from $local_ip to $local_net peer $lan_gw \
        quick auth $quick_auth \
        enc $quick_enc \
        psk $psk_ahb
ike esp from $local_ip to $vpn_gw peer $lan_gw \
        quick auth $quick_auth \
        enc $quick_enc \
        psk $psk_ahb
#------------------------------------------------------------------------------#

ahblaptop <- vpn-gw <- ahb64

#ahblaptop
OpenBSD 4.0 (GENERIC) #1104: Fri Sep  1 11:54:27 MDT 2006
    [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: mobile AMD Athlon(tm) XP 2500+ ("AuthenticAMD" 686-class, 512KB L2 cache) 1.87 GHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real mem  = 536375296 (523804K)

#ahb64
OpenBSD 4.0-current (GENERIC) #1172: Sun Oct 22 20:45:57 MDT 2006
    [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: AMD Athlon(tm) 64 Processor 3000+ ("AuthenticAMD" 686-class, 512KB L2 cache) 1.81 GHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3
cpu0: Cool'n'Quiet K8 1801 MHz: speeds: 1800 1000 MHz
real mem  = 2145873920 (2095580K)

#iperf
0.000313 0.024359 8 1 0.000000 0.000000 0.000008 0.000000 0.000000
0.000312 0.048899 16 2 0.000000 0.000001 0.000006 0.000000 0.000000
0.000313 0.073198 24 3 0.000000 0.000001 0.000007 0.000000 0.000000
0.000311 0.098273 32 4 0.000000 0.000002 0.000009 0.000000 0.000000
0.000312 0.146932 48 6 0.000000 0.000000 0.000009 0.000000 0.000000
0.000309 0.197435 64 8 0.000000 0.000001 0.000010 0.000000 0.000000
0.000320 0.286414 96 12 0.000000 0.000001 0.000002 0.000000 0.000000
0.000319 0.310805 104 13 0.000000 0.000000 0.000002 0.000000 0.000000
0.000318 0.383336 128 16 0.000000 0.000000 0.000003 0.000000 0.000000
0.000318 0.455365 152 19 0.000000 0.000000 0.000001 0.000000 0.000000
0.000322 0.497413 168 21 0.000000 0.000001 0.000002 0.000000 0.000000
0.000319 0.574244 192 24 0.000000 0.000000 0.000006 0.000000 0.000000
0.000335 0.614646 216 27 0.000000 0.000002 0.000011 0.000000 0.000000
0.000333 0.663925 232 29 0.000000 0.000002 0.000008 0.000000 0.000000
0.000332 0.735122 256 32 0.000000 0.000000 0.000003 0.000000 0.000000
0.000333 0.801825 280 35 0.000000 0.000000 0.000013 0.000000 0.000000
0.000342 1.003329 360 45 0.000000 0.000000 0.000003 0.000000 0.000000
0.000344 1.064252 384 48 0.000000 0.000001 0.000009 0.000000 0.000000
0.000343 1.134685 408 51 0.000000 0.000000 0.000010 0.000000 0.000000
0.000353 1.319587 488 61 0.000000 0.000000 0.000020 0.000000 0.000000
0.000354 1.380665 512 64 0.000000 0.000000 0.000016 0.000000 0.000000
0.000353 1.446069 536 67 0.000000 0.000002 0.000015 0.000000 0.000000
0.000374 1.895688 744 93 0.000000 0.000000 0.000013 0.000000 0.000000
0.000374 1.959195 768 96 0.000000 0.000003 0.000015 0.000000 0.000000
0.000375 2.011691 792 99 0.000000 0.000000 0.000012 0.000000 0.000000
0.000392 2.430024 1000 125 0.000000 0.000000 0.000009 0.000000 0.000000
0.000393 2.485865 1024 128 0.000000 0.000000 0.000002 0.000000 0.000000
0.000394 2.539391 1048 131 0.000000 0.000000 0.000002 0.000000 0.000000
0.000433 3.330235 1512 189 0.000000 0.000003 0.000015 0.000000 0.000000
0.000434 3.377881 1536 192 0.000000 0.000000 0.000012 0.000000 0.000000
0.000434 3.429187 1560 195 0.000000 0.000001 0.000013 0.000000 0.000000
0.000472 4.088466 2024 253 0.000000 0.000000 0.000017 0.000000 0.000000
0.000475 4.114641 2048 256 0.000000 0.000000 0.000013 0.000000 0.000000
0.000472 4.189432 2072 259 0.000000 0.000000 0.000015 0.000000 0.000000
0.000556 5.226611 3048 381 0.000000 0.000002 0.000014 0.000000 0.000000
0.000556 5.265245 3072 384 0.000000 0.000000 0.000006 0.000000 0.000000
0.000561 5.263807 3096 387 0.000000 0.000004 0.000020 0.000000 0.000000
0.000649 5.985427 4072 509 0.000000 0.000000 0.000022 0.000000 0.000000
0.000647 6.040619 4096 512 0.000000 0.000000 0.000017 0.000000 0.000000
0.000647 6.076246 4120 515 0.000000 0.000006 0.000006 0.000000 0.000000
0.000789 7.397037 6120 765 0.000000 0.000000 0.000003 0.000000 0.000000
0.000788 7.432691 6144 768 0.000000 0.000000 0.000011 0.000000 0.000000
0.000790 7.442534 6168 771 0.000000 0.000003 0.000011 0.000000 0.000000
0.000957 8.135372 8168 1021 0.000000 0.000000 0.000000 0.000000 0.000000
0.000952 8.205444 8192 1024 0.000000 0.000000 0.000000 0.000000 0.000000
0.000955 8.206924 8216 1027 0.000000 0.000000 0.000013 0.000000 0.000000
0.001283 9.114646 12264 1533 0.000064 0.000000 0.000009 0.000000 0.000000
0.001283 9.132730 12288 1536 0.000000 0.000000 0.000013 0.000000 0.000000
0.001281 9.168192 12312 1539 0.000000 0.000000 0.000009 0.000000 0.000000
0.001285 12.139754 16360 2045 0.000000 0.000000 0.000000 0.000000 0.000000
0.001292 12.093951 16384 2048 0.000000 0.000000 0.000012 0.000000 0.000000
0.001288 12.145593 16408 2051 0.000000 0.000000 0.000023 0.000000 0.000000
0.001430 16.377272 24552 3069 0.000000 0.000006 0.000040 0.000000 0.000000
0.001434 16.344981 24576 3072 0.000000 0.000010 0.000058 0.000000 0.000000
0.001433 16.369108 24600 3075 0.000000 0.000000 0.000048 0.000000 0.000000
0.001474 21.187528 32744 4093 0.000000 0.000000 0.000000 0.000000 0.000000
0.001462 21.372032 32768 4096 0.000000 0.000000 0.000013 0.000000 0.000000
0.001476 21.185052 32792 4099 0.000000 0.000000 0.000026 0.000000 0.000000
0.001760 26.621587 49128 6141 0.000000 0.000000 0.000047 0.000000 0.000000
0.001753 26.734683 49152 6144 0.000000 0.000000 0.000047 0.000000 0.000000
0.001755 26.728457 49176 6147 0.000000 0.000006 0.000029 0.000000 0.000000
0.001958 31.901903 65512 8189 0.000000 0.000000 0.000071 0.000000 0.000000
0.001962 31.850989 65536 8192 0.000000 0.000000 0.000080 0.000000 0.000000
0.001944 32.164503 65560 8195 0.000000 0.000000 0.000035 0.000000 0.000000
0.002477 37.836580 98280 12285 0.000000 0.000000 0.000096 0.000000 0.000000
0.002490 37.651046 98304 12288 0.000000 0.000008 0.000117 0.000000 0.000000
0.002490 37.657277 98328 12291 0.000000 0.000000 0.000178 0.000000 0.000000
0.003027 41.287275 131048 16381 0.000000 0.000000 0.000101 0.000000 0.000000
0.003027 41.292869 131072 16384 0.000000 0.000000 0.000150 0.000000 0.000000
0.003036 41.185079 131096 16387 0.000000 0.000000 0.000245 0.000000 0.000000
0.004162 45.042467 196584 24573 0.000000 0.000000 0.000204 0.000000 0.000000
0.004198 44.663747 196608 24576 0.000000 0.000000 0.000223 0.000000 0.000000
0.004162 45.057183 196632 24579 0.000000 0.000000 0.000229 0.000000 0.000000
0.005118 48.844663 262120 32765 0.000000 0.000000 0.000195 0.000000 0.000000
0.005177 48.294397 262144 32768 0.000000 0.000000 0.000419 0.000000 0.000000
0.005148 48.564431 262168 32771 0.000000 0.000000 0.000233 0.000000 0.000000
0.007147 52.465605 393192 49149 0.000000 0.000000 0.000558 0.000000 0.000000
0.007176 52.254203 393216 49152 0.000000 0.000000 0.000461 0.000000 0.000000
0.007168 52.320459 393240 49155 0.000000 0.000000 0.000558 0.000000 0.000000
0.009214 54.261423 524264 65533 0.000010 0.000000 0.000862 0.000000 0.000000
0.009220 54.231098 524288 65536 0.000000 0.000000 0.000816 0.000000 0.000000
0.009264 53.972798 524312 65539 0.000000 0.000000 0.000644 0.000000 0.000000
0.013281 56.469239 786408 98301 0.000000 0.000043 0.001116 0.000000 0.000000
0.013331 56.258101 786432 98304 0.000000 0.000000 0.001302 0.000000 0.000000
0.013365 56.116515 786456 98307 0.000000 0.000047 0.001023 0.000000 0.000000
0.017328 57.709969 1048552 131069 0.000000 0.000080 0.001116 0.000000 0.000000
0.017311 57.766019 1048576 131072 0.000000 0.000000 0.001276 0.000000 0.000002
0.017259 57.940676 1048600 131075 0.000000 0.000000 0.001993 0.000000 0.000002
0.025227 59.459512 1572840 196605 0.000000 0.000080 0.001834 0.000000 0.000000
0.025340 59.194642 1572864 196608 0.000000 0.000080 0.002471 0.000000 0.000002
0.025136 59.676291 1572888 196611 0.000000 0.000159 0.001993 0.000000 0.000001
0.033512 59.679196 2097128 262141 0.000000 0.000000 0.002710 0.000000 0.000001
0.033294 60.071013 2097152 262144 0.000000 0.000000 0.003268 0.000000 0.000001
0.033320 60.024970 2097176 262147 0.000000 0.000000 0.002870 0.000000 0.000000
0.049282 60.874144 3145704 393213 0.000000 0.000080 0.004624 0.000000 0.000000
0.049394 60.736736 3145728 393216 0.000000 0.000080 0.005341 0.000000 0.000002
0.049443 60.676301 3145752 393219 0.000000 0.000159 0.004544 0.000000 0.000001
0.065287 61.267515 4194280 524285 0.000000 0.000000 0.005979 0.000000 0.000001
0.065569 61.004572 4194304 524288 0.000000 0.000080 0.005501 0.000000 0.000001
0.065350 61.209285 4194328 524291 0.000000 0.000080 0.004783 0.000000 0.000003
0.097040 61.829619 6291432 786429 0.000000 0.000080 0.008291 0.000000 0.000003
0.097420 61.589269 6291456 786432 0.000000 0.000080 0.009088 0.000000 0.000010
0.097466 61.559975 6291480 786435 0.000997 0.000080 0.007733 0.000000 0.000004
0.129270 61.885598 8388584 1048573 0.000000 0.000080 0.013393 0.000000 0.000002
0.130574 61.267706 8388608 1048576 0.000002 0.000080 0.011400 0.000000 0.000003
0.130364 61.366814 8388632 1048579 0.000000 0.000159 0.010922 0.000000 0.000004
0.194323 61.752782 12582888 1572861 0.000024 0.000080 0.018734 0.000000 0.000014
0.194384 61.733613 12582912 1572864 0.000000 0.000080 0.018176 0.000000 0.000005
0.194342 61.746984 12582936 1572867 0.000001 0.000239 0.016103 0.000000 0.000009
0.258006 62.013868 16777192 2097149 0.000001 0.000239 0.024314 0.000000 0.000005
0.258529 61.888592 16777216 2097152 0.000011 0.000319 0.026626 0.000000 0.000004
0.258516 61.891690 16777240 2097155 0.000002 0.000239 0.023039 0.000000 0.000005
0.386869 62.036422 25165800 3145725 0.000038 0.000558 0.036830 0.000000 0.000012
0.386219 62.140933 25165824 3145728 0.000044 0.000239 0.035635 0.000000 0.000009
0.386283 62.130697 25165848 3145731 0.000000 0.000558 0.033960 0.000000 0.000006


# At that highest throughput VPN-host looks like this:
53 processes:  1 running, 49 idle, 2 zombie, 1 on processor
CPU states:  0.0% user,  0.0% nice, 48.1% system,  6.2% interrupt, 45.7% idle
Memory: Real: 34M/118M act/tot  Free: 821M  Swap: 0K/0K used/tot

  PID USERNAME PRI NICE  SIZE   RES STATE    WAIT     TIME    CPU COMMAND
   17 root      14    0    0K   35M run      -       14:49 49.12% crypto

I hope somebody will find this information usefull.

Regards,
ahb

Reply | Threaded
Open this post in threaded view
|

Re: Status of hardware encryption accelerators - wetblanket

Heinrich Rebehn
Andreas Bihlmaier wrote:

> On Mon, Nov 06, 2006 at 09:51:13AM -0800, Dag Richards wrote:
>> Andreas Bihlmaier wrote:
>>> On Mon, Nov 06, 2006 at 09:49:07AM -0700, Darrin Chandler wrote:
>>>> Greg Mortensen wrote:
>>>>> On Sun, 5 Nov 2006, Darrin Chandler wrote:
>>>>>
>>>>>> Can you say what the "irrelevant" i386 machine is? Lots of difference
>>>>>> between a 90MHz PentiumI and a 3GHz Opteron, and I'd like to know where
>>>>>> those numbers fit in.
>>>>> The i386 results were sent to me off-list, so I don't know the
>>>>> processor details. "It's fast" will have to suffice.  To put it in
>>>>> perspective, my fastest Intel systems report:
>>>>>
>>>>> Xeon 3.00GHz
>>>>> aes-128-cbc  56117.94k  59781.24k  62908.69k  63702.29k  63485.95k
>>>>>
>>>>> Xeon 3.40GHz
>>>>> aes-128-cbc  64935.33k  71725.72k  74294.15k  75431.37k  75419.89k
>>>> My fastest:
>>>> cpu0: AMD Opteron(tm) Processor 246, 1994.63 MHz
>>>> cpu1: AMD Opteron(tm) Processor 246, 1994.32 MHz
>>>> type         16 bytes   64 bytes   256 bytes   1024 bytes   8192 bytes
>>>> aes-128-cbc  80713.16k  87876.85k   91431.72k    92622.31k    92688.52k
>>>>
>>>> While that's *more* than fast enough for common tasks, the SBC + VIA
>>>> PadlockACE numbers you gave whip the pants off it for anything > 16 bytes.
>>> Well, you should also consider bytes/watt :)
>>> type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
>>> bytes
>>> aes-128-cbc      48246.54k   175071.41k   472434.09k   788228.58k  
>>> 980033.81k
>>>
>>> OpenBSD 4.0 (GENERIC) #1107: Sat Sep 16 19:15:58 MDT 2006
>>>    [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC
>>> cpu0: VIA Esther processor 1500MHz ("CentaurHauls" 686-class) 1.50 GHz
>>> cpu0:
>>> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,CMOV,PAT,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,SBF,SSE3,EST,TM2
>>>
>>> Regards,
>>> ahb
>>>
>> Those are very impressive numbers.
>> What are you getting through these gateways?
>> What is the net usable throughput client PCs on either end are able to
>> exchange over the VPN?
>
> This is just home usage, all over long 100mbit lines with dirty cheap
> switches (several) in between.
>
> #ipsec.conf (extract):
> #------------------------------- Makros ---------------------------------------#
> quick_enc = "aes"
> quick_auth = "hmac-md5" # <- sha is much more expensive
> ike esp from $local_ip to $local_net peer $lan_gw \
> quick auth $quick_auth \
> enc $quick_enc \
> psk $psk_ahb
> ike esp from $local_ip to $vpn_gw peer $lan_gw \
> quick auth $quick_auth \
> enc $quick_enc \
> psk $psk_ahb
> #------------------------------------------------------------------------------#
>
> ahblaptop <- vpn-gw <- ahb64
>
[snipping dmesg and iperf numbers]

Does anybody know if OpenVPN will also benefit form hardware encryption?

Regards,

Heinrich Rebehn

University of Bremen
Physics / Electrical and Electronics Engineering
- Department of Telecommunications -

Phone : +49/421/218-4664
Fax   :            -3341

Reply | Threaded
Open this post in threaded view
|

Re: Status of hardware encryption accelerators - wetblanket

Joachim Schipper
On Tue, Nov 07, 2006 at 08:21:59AM +0100, Heinrich Rebehn wrote:
> Does anybody know if OpenVPN will also benefit form hardware encryption?

Since it does link against libssl (OpenSSL), which should use hardware
encryption when available, I'd say it should.

                joachim

Reply | Threaded
Open this post in threaded view
|

Re: Status of hardware encryption accelerators

Christian Weisgerber
In reply to this post by Greg Mortensen
Greg Mortensen <[hidden email]> wrote:

>    From a VIA PadlockACE equipped SBC:
>
>               16 bytes    64 bytes     256 bytes    1024 bytes   8192 bytes
> aes-128-cbc  31885.24k   118568.67k   312349.58k   535048.83k   649099.91k
>
>    From a "irrelevant as processors become faster" i386:
>
> aes-128-cbc  61905.43k   83868.59k    91948.85k    93908.47k    93081.82k
>
>    Yawn indeed.

You might also want to post the SHA1 numbers, as long as OpenBSD
doesn't make use of the SHA1/SHA256 support in the C7 Padlock engine.

--
Christian "naddy" Weisgerber                          [hidden email]