I agree with Richard - look at subfile backups.  They have the most
potential for reducing your bandwidth.  Also enable compression if
you haven't already done so, and use 'compressalways yes' to avoid
retransmissions in the event that compression expands a file (rare,
but it can happen).  OS knobs are a good suggestion, if you can do that.

I'm not sure that "doing everything wrong" will lower the bandwidth
requirements, however.  While this *will* slow down your backups,
that doesn't necessarily equate to lower bandwidth.  It can sometimes
increase network overhead.

Depending on the client, journal-based backup (on windows) is another
option that can reduce network traffic, specifically at the beginning
of the backup job.


..Paul

At 01:47 PM 11/3/2006, Richard Sims wrote:

On Nov 3, 2006, at 11:21 AM, Murugan, Palani wrote:

...
I want to know how to configure the schedules and option file so that
less data is sent in each packet therefore reducing the bandwidth
usage
but prolonging the backup it's self.

You can "de-tune" the client by doing things like setting a tiny
TCPWindowsize, a small TXNBytelimit, TCPNodelay Yes, and
MEMORYEFficientbackup Yes.  (Grossly speaking, review the TSM
Performance Tuning Guide and "do everything wrong".)  You can also
employ OS "knobs" to penalize the dsmc process to throttle it.

Beyond that you might look into how realistic Subfile Backups are for
your Windows clients.

   Richard Sims

--
Paul Zarnowski                            Ph: 607-255-4757
Manager, Storage Services                 Fx: 607-255-8521
719 Rhodes Hall, Ithaca, NY 14853-3801    Em: psz1 AT cornell DOT edu