Yes.




"Donald_W._Daniels/FFIC"@ffic.com
06/30/98 01:43 PM


Please respond to ADSM-L AT vm.marist DOT edu

To:   ADSM-L AT vm.marist DOT edu
cc:    (bcc: J Brent Link/COGG/CSC)
Subject:  Re: Undelivered mail




Brent,  in addition to client compression do you also use tape hardware
compression?   We're a new ADSM installation insofar as LAN attached WinNT
servers and NT, OS/2 clients.
Don
ddaniels AT ffic DOT com





jlink2 AT CSC DOT COM (Brent Link) on 06/30/98 08:40:48 AM
To: ADSM-L AT VM.MARIST DOT EDU @ INTERNET
cc:  (bcc: Donald W. Daniels/FFIC)
Subject: Re: Undelivered mail
MAILER AT vm.marist DOT edu
06/30/98 11:12 AM

Please respond to Postmaster AT vm.marist DOT edu
To:   J Brent Link/COGG/CSC
cc:
Subject:  Re: To compress or not to compress?

#1 - nix the newsgroup idea.
#2 - Kelly, here is our 2 cents worth on the             'compression' issue.
You
make  excellent points on this issue.
We have tested this six ways to Sunday.  It is true that by turning compression
off, you will get a faster backup.  This is exponentially true when the client
machine is CPU bound.  However, the only CPU bound machines we found were the
Novell 3.11 servers.  For all others, compression significantly reduces the
overall elapsed time of a backup.  In these (most) cases, the compression on the
client end reduces the amount of data going over the wire.  When we backup at
night, the wire is very much saturated with network load.
What was written about tape compression is true, but not really a factor since
it
isn't the storage media on the host we have been most concerned about.  Our
biggest concern has always been staying in our backup window, and restore
speeds.
For such a large number of machines backing up simultaniously, network
saturation
is the problem to solve.  Compression at the client reduces network saturation.
For restores, consider that for non-compressed backups the amount of band width
required to complete a full restore during prime time and the competition for
bandwidth.  A compressed backup is decompressed on the client end.  During a
full
restore, CPU is never a problem since ADSM is ussually the only thing running.
My recommendation, use client compression as the default.  Only use
non-compressed
for machines that can't tollerate the CPU consumption needs of compression.
Brent
jlink2 AT csc DOT com



This is a rather interesting "feature" of ADSM.  Before a client transmits
data to the server, it asks the server if there is enough room, i.e., the
client specifies exactly how much space is needed to hold the object to be
transmitted.  The server then attempts to make enough room for that object.
 This step is usually successfully completed by disposing of cached data in
a disk pool.  The server only makes as much room as requested.  The key is
it can't make more once the transmission of the object starts.  So, if the
client lies about the size, or the object grows during transmission, you
will get the dreaded "server out of space" message.  How can a file grow?
 If compression is attempted on an already compressed object, it can
actually grow in size.  Files that will display this tendency include zip
files, jpg files, etc.
V3 clients fixed this problem.  If the file actually grew during
compression, then it sent it uncompressed.
I'm an advocate of turning compression off at the client in most cases.
 You only get to compress data once and most tape devices provide
compression.  This is usually hardware compression and more efficient than
most software compression.
Use client compression on clients that are very fast connected to networks
that are very slow or over-utilized.  In many cases turning off compression
will actually improve backup times.
I hope some of this helps...
Kelly Lipp
Storage Solutions Specialists, Inc.
lipp AT storsol DOT com
www.storsol.com
(719) 531-5926