zfs discuss - Jun 2011 - Encryption accelerator card recommendations.

I recently bought an HP Proliant Microserver for a home file server.
( pics and more here:
http://arstechnica.com/civis/viewtopic.php?p=20968192 )

I installed 5 1.5TB (5900 RPM) drives, upgraded the memory to 8GB, and  
installed Solaris 11 Express without a hitch.

A few simple tests using "dd" with 1gb and 2gb files showed excellent
transfer rates: ~200 MB/sec on a 5 drive raidz2 pool, ~310 MB/sec on a  
five drive pool with no redundancy.

That is, until I enabled encryption, which brought the transfer rates  
down to around 20 MB/sec...

Obviously the CPU is the bottleneck here, and I?m wondering what to do next.
I can split the storage into file systems with and without encryption  
and allocate data accordingly. No need, for example, to encrypt open  
source code, or music. But I would like to have everything encrypted  
by default.

My concern is not industrial espionage from a hacker in Belarus, but  
having a disk fail and send it for repair with my credit card  
statements easily readable on it, etc.

I am new to (open or closed)Solaris. I found there is something called  
the Encryption Framework, and that there is hardware support for  
encryption.
This server has two unused PCI-e slots, so I thought a card could be  
the solution, but the few I found seem to be geared to protect SSH and  
VPN connections, etc., not the file system.

Cost is a factor also. I could build a similar server with a much  
faster processor for a few hundred dollars more, so a $1000 dollar  
card for a < $1000 file server is not a reasonable option.

Is there anything out there I could use?

Thanks,

Roberto Waltman

IMO a faster processor with built-in AES and other crypto support is
most likely to give you the most bang for your buck, particularly if
you''re using closed Solaris 11, as Solaris engineering is likely to
add support for new crypto instructions faster than Illumos (but I
don''t really know enough about Illumos to say for sure).

Nico
--

On 6/27/2011 9:55 AM, Roberto Waltman wrote:
> I recently bought an HP Proliant Microserver for a home file server.
> ( pics and more here:
> http://arstechnica.com/civis/viewtopic.php?p=20968192 )
>
> I installed 5 1.5TB (5900 RPM) drives, upgraded the memory to 8GB, and 
> installed Solaris 11 Express without a hitch.
>
> A few simple tests using "dd" with 1gb and 2gb files showed
excellent
> transfer rates: ~200 MB/sec on a 5 drive raidz2 pool, ~310 MB/sec on a 
> five drive pool with no redundancy.
>
> That is, until I enabled encryption, which brought the transfer rates 
> down to around 20 MB/sec...
>
> Obviously the CPU is the bottleneck here, and I?m wondering what to do 
> next.
> I can split the storage into file systems with and without encryption 
> and allocate data accordingly. No need, for example, to encrypt open 
> source code, or music. But I would like to have everything encrypted 
> by default.
>
> My concern is not industrial espionage from a hacker in Belarus, but 
> having a disk fail and send it for repair with my credit card 
> statements easily readable on it, etc.
>
> I am new to (open or closed)Solaris. I found there is something called 
> the Encryption Framework, and that there is hardware support for 
> encryption.
> This server has two unused PCI-e slots, so I thought a card could be 
> the solution, but the few I found seem to be geared to protect SSH and 
> VPN connections, etc., not the file system.
>
> Cost is a factor also. I could build a similar server with a much 
> faster processor for a few hundred dollars more, so a $1000 dollar 
> card for a < $1000 file server is not a reasonable option.
>
> Is there anything out there I could use?
>
> Thanks,
>
> Roberto Waltman 
You''re out of luck.  The hardware-encryption device is seen as a small 
market by the vendors, and they price accordingly. All the solutions are 
FIPS-compliant, which makes them non-trivially expensive to 
build/test/verify.

I have yet to see the "basic" crypto accelerator - which should be as 
simple as an FPGA with downloadable (and updateable) firmware.

The other major cost point is the crypto plugins - sadly, there is no 
way to simply have the CPU farm off crypto jobs to a co-processor. That 
is, there''s no way for the CPU to go "oh, that looks like
I''m running a
crypto algorithm - I should hand it over to the crypto co-processor".  
Instead, you have to write custom plugin/drivers/libraries for each OS, 
and pray that each OS has some standardized crypto framework. Otherwise, 
you have to link apps with custom libraries.

I''m always kind of surprised that there hasn''t been a movement
to create
standardized crypto commands, like the various FP-specific commands that 
are part of MMX/SSE/etc.  That way, most of this could be done in 
hardware seamlessly.



-- 
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA
Timezone: US/Pacific (GMT-0800)

On Mon, June 27, 2011 15:24, Erik Trimble wrote:
[...]
> I''m always kind of surprised that there hasn''t been a
movement to create
> standardized crypto commands, like the various FP-specific commands that
> are part of MMX/SSE/etc.  That way, most of this could be done in
> hardware seamlessly.
The (Ultra)SPARC T-series processors do, but to a certain extent it goes
against a CPU manufacturers best (financial) interest to provide this:
crypto is very CPU intensive using ''regular'' instructions, so
if you need
to do a lot of it, it would force you to purchase a manufacturer''s
top-of-the-line CPUs, and to have as many sockets as you can to handle a
load (and presumably you need to do "useful" work besides just
en/decrypting traffic).

If you have special instructions that do the operations efficiently, it
means that you''re not chewing up cycles as much, so a less powerful
(and
cheaper) processor can be purchased.

I''m sure all the Web 2.0 companies would love to have these (and
OpenSSL
link use the instructions), so they could simply enable HTTPS for
everything. (Of course it''d also be helpful for data-at-rest, on-disk
encryption as well.)

The last benchmarks I saw indicated that the SPARC T-series could do 45
Gb/s AES or some such, with gobs of RSA operations as well.

On 6/27/2011 1:13 PM, David Magda wrote:
> On Mon, June 27, 2011 15:24, Erik Trimble wrote:
> [...]
>> I''m always kind of surprised that there hasn''t been a
movement to create
>> standardized crypto commands, like the various FP-specific commands
that
>> are part of MMX/SSE/etc.  That way, most of this could be done in
>> hardware seamlessly.
> The (Ultra)SPARC T-series processors do, but to a certain extent it goes
> against a CPU manufacturers best (financial) interest to provide this:
> crypto is very CPU intensive using ''regular''
instructions, so if you need
> to do a lot of it, it would force you to purchase a manufacturer''s
> top-of-the-line CPUs, and to have as many sockets as you can to handle a
> load (and presumably you need to do "useful" work besides just
> en/decrypting traffic).
>
> If you have special instructions that do the operations efficiently, it
> means that you''re not chewing up cycles as much, so a less
powerful (and
> cheaper) processor can be purchased.
>
> I''m sure all the Web 2.0 companies would love to have these (and
OpenSSL
> link use the instructions), so they could simply enable HTTPS for
> everything. (Of course it''d also be helpful for data-at-rest,
on-disk
> encryption as well.)
>
> The last benchmarks I saw indicated that the SPARC T-series could do 45
> Gb/s AES or some such, with gobs of RSA operations as well
The T-series crypto isn''t what I''m thinking of.  AFAIK, you
still need
to use the Crypto framework in Solaris to access the on-chip 
functionality. Which makes the T-series no different than CPUs without a 
crypto module but a crypto add-in board instead.

What I''m thinking of is something on the lines of what AMD proposed 
awhile ago, in combination with how we used to handle hardware that had 
FP optional.

That is, you continue to make CPUs without any crypto functionality, 
EXCEPT that they support certain extensions a la MMX.   If no Crypto 
accelerator was available, the CPU would trap any Crypto calls, and 
force them to done in software.  You could then stick a crypto 
accellerator in a second CPU socket, and the CPU would recognized this 
was there, and pipe crypto calls to the dedicated co-processor.

Think about how things were done with the i386 and i387.  That''s what 
I''m after.  With modern CPU buses like AMD & Intel support,
plopping a
"co-processor" into another CPU socket would really, really help.


-- 
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA
Timezone: US/Pacific (GMT-0800)

On Jun 27, 2011, at 17:16, Erik Trimble wrote:
> Think about how things were done with the i386 and i387.  That''s
what I''m after.  With modern CPU buses like AMD & Intel support,
plopping a "co-processor" into another CPU socket would really, really
help.
Given the amount of transistors that are available nowadays I think
it''d be simpler to just create a series of SIMD instructions right
in/on general CPUs, and skip the whole  co-processor angle.

There''s more and more sensitive data out there, so on-disk crypto could
be deployed in more places to help prevent data loss (on both servers and
desktops/laptops), and those systems that don''t do disk IO probably do
network IO, and so would be helped from a TLS/SSL/SSH perspective.

If I were AMD I''d seriously be thinking about this, as it''d
help boost volume and mindshare for a little while with all the folks doing any
kind of web activity would pick up kit for HTTPS?at least until Intel brought
out a similar thing.

On 06/27/11 15:24, David Magda wrote:
> Given the amount of transistors that are available nowadays I think
> it''d be simpler to just create a series of SIMD instructions right
> in/on general CPUs, and skip the whole co-processor angle.
see: http://en.wikipedia.org/wiki/AES_instruction_set

Present in many current Intel CPUs; also expected to be present in
AMD''s
"Bulldozer" based CPUs.

On Jun 27, 2011, at 18:32, Bill Sommerfeld wrote:
> On 06/27/11 15:24, David Magda wrote:
>> Given the amount of transistors that are available nowadays I think
>> it''d be simpler to just create a series of SIMD instructions
right
>> in/on general CPUs, and skip the whole co-processor angle.
> 
> see: http://en.wikipedia.org/wiki/AES_instruction_set
> 
> Present in many current Intel CPUs; also expected to be present in
AMD''s
> "Bulldozer" based CPUs.
Now compare that with the T-series stuff that also handles 3DES, RC4, RSA2048,
DSA, DH, ECC, MD5, SHA1, SHA2, as well as a hardware RNG:

	http://en.wikipedia.org/wiki/UltraSPARC_T2
	http://blogs.oracle.com/BestPerf/entry/20100920_sparc_t3_pk11rsaperf

The initial TLS/SSL set up is actually the expensive part (20-58% of the time
spent of the ''transaction''), and that AES can be performed
decently even on non-AESNI CPUs: simply adding an RSA accelerator can double
performance without session caching, and even ~20%  with it. SSL session caching
alone can help improve throughput by a factor of more than two.

	"Performance Analysis of TLS Web Servers"
	http://www.cs.rice.edu/~dwallach/pub/tls-tocs.pdf
	http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.16.1403

AESNI is certain better than nothing, but RSA, SHA, and the RNG would be nice as
well. It''d also be handy for ZFS crypto in addition to all the network
IO stuff.

FYI There is another thread named -- " GPU acceleration of ZFS" in
this
list to discuss the possibility to utilize the power of GPGPU.
I posted here:

Good day,

I think ZFS can take advantage of using GPU for sha256 calculation, encryption
and maybe compression. Modern video card, like 5xxx or 6xxx ATI HD Series can do
calculation of sha256 50-100 times faster than modern 4 cores CPU.

kgpu project for linux shows nice results.

''zfs scrub'' would work freely on high performance ZFS pools.

The only problem that there is no AMD/Nvidia drivers for Solaris that support
hardware-assisted OpenCL.

Is anyone interested in it?

Best regards,
Anatoly Legkodymov.

On Tue, May 10, 2011 at 11:29 AM, Anatoly <legko777 at fastmail.fm>
wrote:
> Good day,
>
> I think ZFS can take advantage of using GPU for sha256 calculation, 
> encryption and maybe compression. Modern video card, like 5xxx or 6xxx 
> ATI HD Series can do calculation of sha256 50-100 times faster than 
> modern 4 cores CPU.
Ignoring optimizations from SIMD extensions like SSE and friends, this is
probably true. However, the GPU also has to deal with the overhead of data
transfer to itself before it can even begin crunching data.
Granted, a Gen. 2 x16 link is quite speedy, but is CPU performance really that
poor where a GPU can still out-perform it? My undergrad thesis dealt with
computational acceleration utilizing CUDA, and the datasets had to scale quite a
ways before there was a noticeable advantage in using a Tesla or similar over a
bog-standard i7-920.
> The only problem that there is no AMD/Nvidia drivers for Solaris that 
> support hardware-assisted OpenCL.
This, and keep in mind that most of the professional users here will likely be
using professional hardware, where a simple 8MB Rage XL gets the job done thanks
to the magic of out-of-band management cards and other such facilities. Even as
a home user, I have not placed a high-end videocard into my machine, I use a $5
ATI PCI videocard that saw about a hour of use whilst I installed Solaris 11.

--
--khd

IMHO, zfs need to run in all kind of HW
T-series CMT server that can help sha calculation since T1 day, did not see any
work in ZFS to take advantage it


On 5/10/2011 11:29 AM, Anatoly wrote:
> Good day,
>
> I think ZFS can take advantage of using GPU for sha256 calculation, 
> encryption and maybe compression. Modern video card, like 5xxx or 6xxx 
> ATI HD Series can do calculation of sha256 50-100 times faster than 
> modern 4 cores CPU.
>
> kgpu project for linux shows nice results.
>
> ''zfs scrub'' would work freely on high performance ZFS
pools.
>
> The only problem that there is no AMD/Nvidia drivers for Solaris that 
> support hardware-assisted OpenCL.
>
> Is anyone interested in it?
>
> Best regards,
> Anatoly Legkodymov.
On Tue, May 10, 2011 at 10:29 PM, Anatoly <legko777 at fastmail.fm>
wrote:
> Good day,
>
> I think ZFS can take advantage of using GPU for sha256 calculation, 
> encryption and maybe compression. Modern video card, like 5xxx or 6xxx 
> ATI HD Series can do calculation of sha256 50-100 times faster than 
> modern 4 cores CPU.
>
> kgpu project for linux shows nice results.
>
> ''zfs scrub'' would work freely on high performance ZFS
pools.
>
> The only problem that there is no AMD/Nvidia drivers for Solaris that 
> support hardware-assisted OpenCL.
>
> Is anyone interested in it?
This isn''t technically true.  The NVIDIA drivers support compute, but
there''s other parts of the toolchain missing.  /* I don''t know
about ATI/AMD, but I''d guess they likely don''t support compute
across platforms */



/* Disclaimer - The company I work for has a working HMPP compiler for
Solaris/FreeBSD and we may soon support CUDA */

On 10 May 2011, at 16:44, Hung-Sheng Tsao (LaoTsao) Ph. D. wrote:
> 
> IMHO, zfs need to run in all kind of HW T-series CMT server that can 
> help sha calculation since T1 day, did not see any work in ZFS to take 
> advantage it
That support would be in the crypto framework though, not ZFS per se. So I think
the OP might consider how best to add GPU support to the crypto framework.

Chris
_______________________________________________


Thanks.

Fred
> -----Original Message-----
> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss-
> bounces at opensolaris.org] On Behalf Of David Magda
> Sent: ???, ?? 28, 2011 9:23
> To: Bill Sommerfeld
> Cc: zfs-discuss at opensolaris.org
> Subject: Re: [zfs-discuss] Encryption accelerator card recommendations.
> 
> On Jun 27, 2011, at 18:32, Bill Sommerfeld wrote:
> 
> > On 06/27/11 15:24, David Magda wrote:
> >> Given the amount of transistors that are available nowadays I
think
> >> it''d be simpler to just create a series of SIMD
instructions right
> >> in/on general CPUs, and skip the whole co-processor angle.
> >
> > see: http://en.wikipedia.org/wiki/AES_instruction_set
> >
> > Present in many current Intel CPUs; also expected to be present in
> AMD''s
> > "Bulldozer" based CPUs.
> 
> Now compare that with the T-series stuff that also handles 3DES, RC4,
> RSA2048, DSA, DH, ECC, MD5, SHA1, SHA2, as well as a hardware RNG:
> 
> 	http://en.wikipedia.org/wiki/UltraSPARC_T2
> 	http://blogs.oracle.com/BestPerf/entry/20100920_sparc_t3_pk11rsap
> erf
> 
> The initial TLS/SSL set up is actually the expensive part (20-58% of
> the time spent of the ''transaction''), and that AES can be
performed
> decently even on non-AESNI CPUs: simply adding an RSA accelerator can
> double performance without session caching, and even ~20%  with it. SSL
> session caching alone can help improve throughput by a factor of more
> than two.
> 
> 	"Performance Analysis of TLS Web Servers"
> 	http://www.cs.rice.edu/~dwallach/pub/tls-tocs.pdf
> 	http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.16.1403
> 
> AESNI is certain better than nothing, but RSA, SHA, and the RNG would
> be nice as well. It''d also be handy for ZFS crypto in addition to
all
> the network IO stuff.
> 
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

On Jun 27, 2011, at 22:03, Fred Liu wrote:
> FYI There is another thread named -- " GPU acceleration of ZFS"
in this
> list to discuss the possibility to utilize the power of GPGPU.
> I posted here:
In a similar vein I recently came across SSLShader:

	http://shader.kaist.edu/sslshader/
	http://www.usenix.org/event/nsdi11/tech/full_papers/Jang.pdf

	http://www.google.com/search?q=sslshader

This could be handy for desktops doing ZFS crypto (and even browser SSL and/or
SSH), but few servers have decent graphics cards (and SPARC systems
don''t even have video ports by :).

On Jun 27, 2011 9:24 PM, "David Magda" <dmagda at ee.ryerson.ca>
wrote:
> AESNI is certain better than nothing, but RSA, SHA, and the RNG would be
nice as well. It''d also be handy for ZFS crypto in addition to all the
network IO stuff.

The most important reason for AES-NI might be not performance but defeating
side-channel attacks.

Also, really fast AES HW makes AES-based hash functions quite tempting.

No, AES-NI is nothing to sneeze at.

Nico
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20110627/38f922fd/attachment.html>

On Jun 27, 2011 4:15 PM, "David Magda" <dmagda at ee.ryerson.ca>
wrote:
> The (Ultra)SPARC T-series processors do, but to a certain extent it goes
> against a CPU manufacturers best (financial) interest to provide this:
> crypto is very CPU intensive using ''regular''
instructions, so if you need
> to do a lot of it, it would force you to purchase a manufacturer''s
> top-of-the-line CPUs, and to have as many sockets as you can to handle a
> load (and presumably you need to do "useful" work besides just
> en/decrypting traffic).
I hope no CPU vendor thinks about the economics of chip making that way.  I
actually doubt any do.

Nico
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20110627/5fdbd8c9/attachment.html>

On Tue, June 28, 2011 13:55, Fritz Wuehler wrote:
>> Now compare that with the T-series stuff that also handles 3DES, RC4,
>> RSA2048, DSA, DH, ECC, MD5, SHA1, SHA2, as well as a hardware RNG:
>>
>> 	http://en.wikipedia.org/wiki/UltraSPARC_T2
>> 	http://blogs.oracle.com/BestPerf/entry/20100920_sparc_t3_pk11rsaperf
>
> Do you know if this is true of the crypto cards for Sun Fire servers? And
> how do I check whether my units have this card? I received several second
> hand servers and didn''t get a complete list of what they have.
Please
> reply to the mailing list, thanks.
All (Ultra)SPARC T2, T2+, and T3 CPUs should have these capabilities; if
you have some other CPU the capabilities are probably not present. Run
''prtdiag | head -20'' to see the CPUs on your system/s; run
cryptoadm(1M)
with the  "list" option (Solaris 10+) to see the software and hardware
providers available.

For further assistance your best bet would be  "crypto-discuss" (this
has
gotten OT for zfs-discuss):

   http://mail.opensolaris.org/pipermail/crypto-discuss/

On 06/27/11 11:32 PM, Bill Sommerfeld wrote:
> On 06/27/11 15:24, David Magda wrote:
>> Given the amount of transistors that are available nowadays I think
>> it''d be simpler to just create a series of SIMD instructions
right
>> in/on general CPUs, and skip the whole co-processor angle.
> see: http://en.wikipedia.org/wiki/AES_instruction_set
>
> Present in many current Intel CPUs; also expected to be present in
AMD''s
> "Bulldozer" based CPUs.
I recall seeing a blog comparing the existing Solaris hand-tuned AES 
assembler performance with the (then) new AES instruction version, where 
the Intel AES instructions only got you about a 30% performance 
increase. I''ve seen reports of better performance improvements, but 
usually by comparing with the performance on older processors which are 
going to be slower for additional reasons then just missing the AES 
instructions. Also, you could claim better performance improvement if 
you compared against a less efficient original implementation of AES. 
What this means is that a faster CPU may buy you more crypto performance 
than the AES instructions alone will do.

My understanding from reading the Intel AES instruction set (which I 
warn might not be completely correct) is that the AES 
encryption/decryption instruction is executed between 10 and 14 times 
(depending on key length) for each 128 bits (16 bytes) of data being 
encrypted/decrypted, so it''s very much part of the regular instruction 
pipeline. The code will have to loop though this process multiple times 
to process a data block bigger than 16 bytes, i.e. a double nested loop, 
although I expect it''s normally loop-unrolled a fair degree for 
optimisation purposes.

Conversely, the crypto units in the T-series processors are separate 
from the CPU, and do the encryption/decryption whilst the CPU is getting 
on with something else, and they do it much faster than it could be done 
on the CPU. Small blocks are normally a problem for crypto offload 
engines because the overhead of farming off the work to the engine and 
getting the result back often means that you can do the crypto on the 
CPU faster than the time it takes to get the crypto engine started and 
stopped. However, T-series crypto is particularly good at handling small 
blocks efficiently, such as around 1kbyte which you are likely to find 
in a network packet, as it is much closer coupled to the CPU than a PCI 
crypto card can be, and performance with small packets was key for the 
crypto networking support T-series was designed for. Of course, it 
handles crypto of large blocks just fine too.

-- 
Andrew

> All (Ultra)SPARC T2, T2+, and T3 CPUs should have these capabilities; if
> you have some other CPU the capabilities are probably not present. Run
> ''prtdiag | head -20'' to see the CPUs on your system/s;
run cryptoadm(1M)
> with the  "list" option (Solaris 10+) to see the software and
hardware
> providers available.
> 
> For further assistance your best bet would be  "crypto-discuss"
(this has
> gotten OT for zfs-discuss):
> 
>    http://mail.opensolaris.org/pipermail/crypto-discuss/
Thanks, I''ll ask over there. I understood there was a broadcomm add on
card
for servers but from your answer it seems the CPU supports crypto
operations. I don''t understand what the purpose of having both support
it is
if they want to sell crypto cards.

> -----Original Message-----
> From: David Magda [mailto:dmagda at ee.ryerson.ca]
> Sent: ???, ?? 28, 2011 10:41
> To: Fred Liu
> Cc: Bill Sommerfeld; ZFS Discuss
> Subject: Re: [zfs-discuss] Encryption accelerator card
> recommendations.[GPU acceleration of ZFS]
> 
> On Jun 27, 2011, at 22:03, Fred Liu wrote:
> 
> > FYI There is another thread named -- " GPU acceleration of
ZFS" in
> this
> > list to discuss the possibility to utilize the power of GPGPU.
> > I posted here:
> 
> In a similar vein I recently came across SSLShader:
> 
> 	http://shader.kaist.edu/sslshader/
> 	http://www.usenix.org/event/nsdi11/tech/full_papers/Jang.pdf
> 
> 	http://www.google.com/search?q=sslshader
> 
> This could be handy for desktops doing ZFS crypto (and even browser SSL
> and/or SSH), but few servers have decent graphics cards (and SPARC
> systems don''t even have video ports by :).
> 
Agree. The most challenging part is coding as long as there is an empty PCIE
slot in server.

Thanks.

Fred

>On Jun 27, 2011, at 17:16, Erik Trimble wrote:
>
>> Think about how things were done with the i386 and i387. 
That''s what I''m> after.  With modern CPU buses like AMD
& Intel support, plopping a "co-pro>cessor" into another CPU
socket would really, really help.
>
>Given the amount of transistors that are available nowadays I think
it''d be> simpler to just create a series of SIMD instructions right
in/on general C>PUs, and skip the whole  co-processor angle.
One of the VIA processors was one of the first with specific random and 
AES instructions.  AMD & Intel have followed suite and your can some 
information here:

http://en.wikipedia.org/wiki/AES_instruction_set

(Similar instructions have been added for SHA, MD5 (older CPUs), RSA,
though typically using building blocks not a single long running 
instruction)

A number of the "crypto accelerators" were much slower than the 
implementation of a direct implementation in opcodes; one issue, though, 
what register sets will be used and where will it be saved when the thread
is preempted (I''m assuming that the reason why AMD and Intel use
different
instructions from VIA is possibly because of such details.

The current implementation the T3 uses a co-processor (one per core, I 
think)

Casper

Thanks for this pointer ... I have been looking for a small (low
power) "server" for a bit now and did not realize that HP had anything
in the line below the ML-1xx.

    One of the reviews at the HP site note that the 5.25" media bay is
IDE only (from a BIOS perspective), can you confirm or deny this ? I
really want 6 drives (2 x 250 GB OS, 4 x 1 TB data), and using the
5.25" bay plus the eSata I can get there. Although if I can use a
couple 16 GB USB flash drives for OS I *might* go that route.

I am not planning on using encryption, so the CPU is probably not a
limitation for me.

On Mon, Jun 27, 2011 at 12:55 PM, Roberto Waltman <lists at rwaltman.com>
wrote:
> I recently bought an HP Proliant Microserver for a home file server.
> ( pics and more here:
> http://arstechnica.com/civis/viewtopic.php?p=20968192 )
>
> I installed 5 1.5TB (5900 RPM) drives, upgraded the memory to 8GB, and
> installed Solaris 11 Express without a hitch.
>
> A few simple tests using "dd" with 1gb and 2gb files showed
excellent
> transfer rates: ~200 MB/sec on a 5 drive raidz2 pool, ~310 MB/sec on a five
> drive pool with no redundancy.
>
> That is, until I enabled encryption, which brought the transfer rates down
> to around 20 MB/sec...
-- 
{--------1---------2---------3---------4---------5---------6---------7---------}
Paul Kraus
-> Senior Systems Architect, Garnet River ( http://www.garnetriver.com/ )
-> Sound Coordinator, Schenectady Light Opera Company (
http://www.sloctheater.org/ )
-> Technical Advisor, RPI Players

On 06/29/2011 07:49 AM, Paul Kraus wrote:
> Thanks for this pointer ... I have been looking for a small (low
> power) "server" for a bit now and did not realize that HP had
anything
> in the line below the ML-1xx.
>
>      One of the reviews at the HP site note that the 5.25" media bay
is
> IDE only (from a BIOS perspective), can you confirm or deny this ? I
> really want 6 drives (2 x 250 GB OS, 4 x 1 TB data), and using the
> 5.25" bay plus the eSata I can get there. Although if I can use a
> couple 16 GB USB flash drives for OS I *might* go that route.
Yes and no. Both the Optical Drive bay and the esata port work in IDE 
mode, if you use the official HP BIOS.

They both work as AHCI ports after flashing a patched bios from a 
Russian web site. Caveat emptor...

I saw pictures somewhere of somebody shoehorning 6 drives, two 3.5" 
drives side by side on the top shelf, one of them connected to the 
external esata port.

Other installed a sata controller in one of the PCI-e slots. This avoids 
the cable going out and back in again and the BIOS issue.

If you are creative, there is enough room for one or two 2.5" solid 
state drives, above/below the 5.25 bay or by the back wall.
One could be connected to the internal USB port with a USB powered sata 
adapter.

Or, you could use bigger capacity drives and use one partition for the 
OS, as I did.

I would recommend against 6 mechanical drives because of 
cooling/air-flow issues. I used an AMS SATA removable rack, ( 
www.amselectronics.com/DS_136SSBK.pdf ), partially because of the 
built-in fan.

Last but not least, don''t forget the PS is only 200 watt, which reminds
me: be aware, there are two identically looking models - One comes with 
a 250Gb disk and a 160 Watt PS, the other with a 160Gb disk and a 200 
Watt PS.

I have a few URLs you may find useful, will post them this evening. Can 
take a couple pics of my setup, but that will have to wait until the 
weekend.

-- 
Roberto Waltman

Paul Kraus wrote:
> Thanks for this pointer ... I have been looking for a small (low
> power) "server" for a bit now and did not realize that HP had
anything
> in the line below the ML-1xx.
>
>     One of the reviews at the HP site note that the 5.25" media bay is
> IDE only (from a BIOS perspective), can you confirm or deny this ? I
> really want 6 drives (2 x 250 GB OS, 4 x 1 TB data), and using the
> 5.25" bay plus the eSata I can get there. Although if I can use a
> couple 16 GB USB flash drives for OS I *might* go that route.
>
> I am not planning on using encryption, so the CPU is probably not a
> limitation for me.
>
> On Mon, Jun 27, 2011 at 12:55 PM, Roberto Waltman <lists at
rwaltman.com> wrote:
>> I recently bought an HP Proliant Microserver for a home file server.
>> ( pics and more here:
>> http://arstechnica.com/civis/viewtopic.php?p=20968192 )
>>
>> I installed 5 1.5TB (5900 RPM) drives, upgraded the memory to 8GB, and
>> installed Solaris 11 Express without a hitch.
>>
>> A few simple tests using "dd" with 1gb and 2gb files showed
excellent
>> transfer rates: ~200 MB/sec on a 5 drive raidz2 pool, ~310 MB/sec on a
five
>> drive pool with no redundancy.
>>
>> That is, until I enabled encryption, which brought the transfer rates
down
>> to around 20 MB/sec...
I did reply before, but I don''t see my response in the list, so here  
it goes again.
> ? can you confirm or deny this ?
I can do both!  ;)

The disk controller ports #4 (esata,) and #5 (optical drive bay,) work  
in IDE mode if you use an official HP BIOS.  They can be configured to  
work in AHCI mode after flashing a patched BIOS from a Russian  
website.  Caveat emptor?

Some people installed a SATA controller in one of the PCI-e slots.  
That solves the BIOS issue as well as the problem of routing a cable  
in and out to connect an internal disk to the external SATA port. (If  
you go for 6 drives, more below) But I don?t recall a report using  
this combination with ZFS/Solaris.

There is a long thread here:   
http://hardforum.com/showthread.php?t=1555868 , with some useful  
information, including pictures of a 6 disk arrangement.

I would recommend against doing something like that, because of  
cooling/air-flow issues in addition to loosing the ability to change  
drives quickly.

I installed 4 drives in the drive cage and a fifth one in an AMS  
removable rack. I chose this one  
http://www.amselectronics.com/DS_136SSBK.pdf partially because of the  
built-in fan.

If you are creative, there is still room to install one or two 2.5?  
solid state drives above/below the 5? bay or flat against the back  
wall. Three or more for 1.8? drives. One can be easily plugged to the  
internal USB connector using a bus powered USB to SATA adapter.  For  
more than one, or for speed, you will need a SATA controller.

Be aware that there are two identically looking models; one comes with  
a 250Gb disk and a 160 Watt PS, the other with a 160Gb disk and a 200  
Watt PS.  Make sure you get the later.

I can get a few pictures of my setup, but that will have to wait for  
the weekend.

Another review, with power and temperature measurements:  
http://www.silentpcreview.com/HP_Proliant_MicroServer

Finally, if you want to occasionally use for desktop duty, the  
graphics are a little sluggish. Nvidia has a few PCI-e x1 cards (PNY  
Quadro NVS,) that consume between 17 and 25 watts. They claim driver  
support for Solaris.

--
Roberto Waltman

Paul Kraus wrote:
> Thanks for this pointer ... I have been looking for a small (low
> power) "server" for a bit now and did not realize that HP had
anything
> in the line below the ML-1xx.
>
>     One of the reviews at the HP site note that the 5.25" media bay is
> IDE only (from a BIOS perspective), can you confirm or deny this ? I
> really want 6 drives (2 x 250 GB OS, 4 x 1 TB data), and using the
> 5.25" bay plus the eSata I can get there. Although if I can use a
> couple 16 GB USB flash drives for OS I *might* go that route.
>
> I am not planning on using encryption, so the CPU is probably not a
> limitation for me.
>
> On Mon, Jun 27, 2011 at 12:55 PM, Roberto Waltman <lists at
rwaltman.com> wrote:
>> I recently bought an HP Proliant Microserver for a home file server.
>> ( pics and more here:
>> http://arstechnica.com/civis/viewtopic.php?p=20968192 )
>>
>> I installed 5 1.5TB (5900 RPM) drives, upgraded the memory to 8GB, and
>> installed Solaris 11 Express without a hitch.
>>
>> A few simple tests using "dd" with 1gb and 2gb files showed
excellent
>> transfer rates: ~200 MB/sec on a 5 drive raidz2 pool, ~310 MB/sec on a
five
>> drive pool with no redundancy.
>>
>> That is, until I enabled encryption, which brought the transfer rates
down
>> to around 20 MB/sec...
I did reply before, but I don''t see my response in the list, so here  
it goes again.
> ? can you confirm or deny this ?
I can do both!  ;)

The disk controller ports #4 (esata,) and #5 (optical drive bay,) work  
in IDE mode if you use an official HP BIOS.  They can be configured to  
work in AHCI mode after flashing a patched BIOS from a Russian  
website.  Caveat emptor?

Some people installed a SATA controller in one of the PCI-e slots.  
That solves the BIOS issue as well as the problem of routing a cable  
in and out to connect an internal disk to the external SATA port. (If  
you go for 6 drives, more below) But I don?t recall a report using  
this combination with ZFS/Solaris.

There is a long thread here:   
http://hardforum.com/showthread.php?t=1555868 , with some useful  
information, including pictures of a 6 disk arrangement.

I would recommend against doing something like that, because of  
cooling/air-flow issues in addition to loosing the ability to change  
drives quickly.

I installed 4 drives in the drive cage and a fifth one in an AMS  
removable rack. I chose this one  
http://www.amselectronics.com/DS_136SSBK.pdf partially because of the  
built-in fan.

If you are creative, there is still room to install one or two 2.5?  
solid state drives above/below the 5? bay or flat against the back  
wall. Three or more for 1.8? drives. One can be easily plugged to the  
internal USB connector using a bus powered USB to SATA adapter.  For  
more than one, or for speed, you will need a SATA controller.

Be aware that there are two identically looking models; one comes with  
a 250Gb disk and a 160 Watt PS, the other with a 160Gb disk and a 200  
Watt PS.  Make sure you get the later.

I can get a few pictures of my setup, but that will have to wait for  
the weekend.

Another review, with power and temperature measurements:  
http://www.silentpcreview.com/HP_Proliant_MicroServer

Finally, if you want to occasionally use for desktop duty, the  
graphics are a little sluggish. Nvidia has a few PCI-e x1 cards (PNY  
Quadro NVS,) that consume between 17 and 25 watts. They claim driver  
support for Solaris.

--
Roberto Waltman