<div dir="ltr"><br><br><div class="gmail_quote">2008/10/2 Bill Broadley <span dir="ltr"><<a href="mailto:bill@cse.ucdavis.edu" target="_blank">bill@cse.ucdavis.edu</a>></span><br><br><...><br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Why hardware?  I have some python code that managed 10MB/sec per CPU (or 80MB<br>
on 8 CPUs if you prefer) that compresses with zlib, hashes with sha256, and<br>
encrypts with AES (256 bit key).  Assuming the compression you want isn't<br>
substantially harder than doing zlib, sha256, and aes a single core from a<br>
dual or quad core chip sold in the last few years should do fine.<br>
<br>
1TB every 2 days = 6MB/sec or approximately 15% of a quad core or 60% of a<br>
single core for my compress, hash and encrypt in python.  Considering how<br>
cheap cores are (quad desktops are often under $1k) I'm not sure what would<br>
justify an accelerator card.  Not to mention picking the particular algorithm<br>
could make a huge difference to the CPU and compression ratio achieved.  I'd<br>
recommend taking a stack of real data and trying out different compression<br>
tools and settings.<br>
<br>
In any case 6MB/sec of compression isn't particularly hard these days.... even<br>
in python on a 1-2 year old mid range cpu.<div><div></div><div><br>
<br>
</div></div></blockquote><div><br>In Information Retrieval, they compress almost everything and they have
papers showing that using compression can result in a *faster* system.
You process a little more, but get great gains in disk throughput. <br>If you compress before even storing data, your system could store faster by using less disk/storage bandwidth per stored file.<br>
<br><br> </div></div></div>