Dwight,

You are correct that compressed data would not encrypt well, since TSM
uses a compression algorithm that works well with redundant data (and
compression kills redundancy) - but, the TSM b/a client does in fact
compress first and then encrypt the data to avoid this.   So go ahead and
use both encryption and compression if you would like.

I don't have any performance data from development on the b/a client using
encryption.  What we did test in development was the b/a client vs. plain
DES 56-bit encryption algorithms to make sure the client was not adding
unnecessary overhead.  DES is allot of number crunching, and it is by
nature very CPU intensive and will slow the b/a client down noticeably.

Thanks,
Jim Smith
TSM Client Development


Been a while and I'd have to double check but...
You might not want to use compression if you use encryption...
I believe it encrypts first then tries to compress and encrypted data
doesn't compress (much).
Something to double check.

Dwight



-----Original Message-----
From: J D Gable [mailto:josh.gable AT eds DOT com]
Sent: Monday, October 21, 2002 4:13 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Encryption


Does anybody have any evidence/research as to what kind of additional
overhead encryption puts on a client when processing a backup (CPU,
Memory, etc.)?  I am running some tests myself, but the numbers are
staggering (we're seeing up to a 300% increase in the backup time in
some cases).  I understand that it is largely based on the horsepower of
the node, but I was wondering if anyone else is seeing the same, or if
anyone knew a place I could get some additional info on encryption.

Thanks in advance for your time,
Josh