I don't think that LARGECOMMBUFFERS and USELARGEBUFFERS are related, at
least not directly.

In general, USELARGEBUFFERS YES on the TSM server helps improve server
throughput and efficiency for large files. I've seen no suggestion to set
it to NO, even on Windows.

he LARGECOMMBUFFERS client option can help improve client
throughput/efficiency, but I'm pretty sure that it relies on the OS disk
read-ahead ability to achieve that performance improvement (other factors
include amount of system memory, disk speed, etc.). On Windows, our
testing has found that, especially for small files, setting
LARGECOMMBUFFERS YES doesn't help, and is in fact, detrimental. For
example, I just did a little test myself on Windos 2000. I have a test
directory containing 62 files, each file being exactly 100,000 bytes in
size. WIth LARGECOMMBUFFERS NO, the backup took around 7 seconds. With
LARGECOMMBUFFERS YES, the backup took around 12 seconds.

Generally speaking, there are very few absolutes in life, and TSM options
are no exception (if they were, we would just hard-code the values and not
make them options). Sometimes bigger is not always better. You should
experiment with which settings work best for your environment. In some
cases, such as very fast systems with lots of memory, very fast disks, and
large average file sizes, LARGECOMMBUFFERS YES might be helpful; but to
start, I'd suggest LARGECOMMBUFFERS NO for Windows. On AIX, our testing
indicates that setting it to YES is usually a good idea, so that's why
it's default is YES. I have no experience in testing these settings on the
other platforms, and I am not a performance guru, so in lieu of anything
else, go with the settings that you are accustomed to. But... it might not
be a bad idea ot run some benchmarks with different settings, just to
validate what you are doing.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.


Josuha wrote:

That is a new one on me.  Per the last Performance Tuning Guide, a bit
long in the tooth, LARGECOMMBUFFERS was recommended Yes.

So let me get this straight:

Windows clients - set LARGECOMMBUFFERS to No
UNIX, Novelll, etc. - set LARGECOMMBUFFERS to Yes

How about UNIX clients backing up to a TSM Server on Windows?

...........

Neil wrote:

Andy

You say we should be settting LargeCommBuffers to No (the default) on
Windows clients.

How does this relate - if at all - to the UseLargeBuffers server option,
the default for which is Yes? Should we be changing this if we are running
TSM Server on NT?