Re: Status of hardware encryption accelerators
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
Re: Status of hardware encryption accelerators - wetblanket
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
Re: Status of hardware encryption accelerators
Greg Mortensen [EMAIL PROTECTED] wrote: From a VIA PadlockACE equipped SBC: 16 bytes64 bytes 256 bytes1024 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.59k91948.85k93908.47k93081.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 [EMAIL PROTECTED]
Re: Status of hardware encryption accelerators
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 \|/ ___ \|/[EMAIL PROTECTED]+- 2048R/38BD6CAB -+ @~./'O o`\.~@| 02BD EF81 91B3 1B33 64C2 | /__( \___/ )__\ | 3247 6722 7006 38BD 6CAB | `\__`U_/' +--+
Re: Status of hardware encryption accelerators
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.72k92622.31k92688.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 [EMAIL PROTECTED] | http://bsd.phoenix.az.us/ http://www.stilyagin.com/ |
Re: Status of hardware encryption accelerators - wetblanket
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.72k92622.31k92688.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 bytes256 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 [EMAIL PROTECTED]:/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?
Re: Status of hardware encryption accelerators - wetblanket
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.72k92622.31k92688.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 bytes256 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 [EMAIL PROTECTED]:/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 [EMAIL PROTECTED]:/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 [EMAIL PROTECTED]:/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.00 0.00 0.08 0.00 0.00 0.000312 0.048899 16 2 0.00 0.01 0.06 0.00 0.00 0.000313 0.073198 24 3 0.00 0.01 0.07 0.00 0.00 0.000311 0.098273 32 4 0.00 0.02 0.09 0.00 0.00 0.000312 0.146932 48 6 0.00 0.00 0.09 0.00 0.00 0.000309 0.197435 64 8 0.00 0.01 0.10 0.00 0.00 0.000320 0.286414 96 12 0.00 0.01 0.02 0.00 0.00 0.000319 0.310805 104 13 0.00 0.00 0.02 0.00 0.00 0.000318 0.383336 128 16 0.00 0.00 0.03 0.00 0.00 0.000318 0.455365 152 19 0.00 0.00 0.01 0.00 0.00 0.000322 0.497413 168 21 0.00 0.01 0.02 0.00 0.00 0.000319 0.574244 192 24 0.00 0.00 0.06 0.00 0.00 0.000335 0.614646 216 27 0.00 0.02 0.11 0.00 0.00 0.000333 0.663925 232 29 0.00 0.02 0.08 0.00 0.00 0.000332 0.735122 256 32 0.00 0.00 0.03 0.00 0.00 0.000333 0.801825 280 35 0.00 0.00 0.13 0.00 0.00 0.000342 1.003329 360 45 0.00 0.00 0.03 0.00 0.00 0.000344 1.064252 384 48 0.00 0.01 0.09 0.00 0.00 0.000343 1.134685 408 51 0.00 0.00 0.10 0.00 0.00 0.000353 1.319587 488 61 0.00 0.00 0.20 0.00 0.00 0.000354 1.380665 512 64 0.00 0.00 0.16 0.00 0.00 0.000353 1.446069 536 67 0.00 0.02 0.15 0.00 0.00 0.000374 1.895688 744 93 0.00 0.00 0.13 0.00 0.00 0.000374 1.959195 768 96 0.00 0.03 0.15 0.00 0.00 0.000375 2.011691 792 99 0.00
Re: Status of hardware encryption accelerators
On Sat, Nov 04, 2006 at 11:09:56PM -0500, Greg Mortensen wrote: Darrin Chandler [EMAIL PROTECTED] wrote: For desktop/server use, hardware acceleration for crypto seems increasingly irrelevant as processors become faster. Yawn. From a VIA PadlockACE equipped SBC: 16 bytes64 bytes 256 bytes1024 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.59k91948.85k93908.47k93081.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.62k2766.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 [EMAIL PROTECTED] | http://bsd.phoenix.az.us/ http://www.stilyagin.com/ |
Status of hardware encryption accelerators
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
Re: Status of hardware encryption accelerators
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | http://bsd.phoenix.az.us/ http://www.stilyagin.com/ |
Re: Status of hardware encryption accelerators
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 [EMAIL PROTECTED] | http://bsd.phoenix.az.us/ http://www.stilyagin.com/ |
Re: Status of hardware encryption accelerators
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 [EMAIL PROTECTED] | http://bsd.phoenix.az.us/ http://www.stilyagin.com/ |
Re: Status of hardware encryption accelerators
Bhima, Quoting Bhima Pandava [EMAIL PROTECTED]: 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
