>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 transisto
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 t
> -Original Message-
> From: David Magda [mailto:dma...@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]
>
>
> 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
> p
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.wi
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/20100
On Jun 27, 2011 4:15 PM, "David Magda" 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 woul
On Jun 27, 2011 9:24 PM, "David Magda" 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-channe
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/
hink the OP might consider how best to add GPU support to the crypto framework.
Chris
___
Thanks.
Fred
> -Original Message-
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of
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.
>
>
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
Prese
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 tha
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
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.
Th
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 wit
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 a
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"
18 matches
Mail list logo
