In <bitnet.adsm-l%199512262208.RAA21412 AT comet.connix DOT com>, raibeck AT 
connix DOT com (Andy Raibeck) writes:
>Tim Pittson writes:
>
><---- Begin Forwarded Message ---->
>     I was wondering if anybody has had a chance to experiment with these
>parameters on the client (txnbytelimit) or the ADSM server (txngroupmax).
> I'd be interested to hear about any experiences (better performance, etc.).
> Was thinking of raising the txngroupmax parameter on our ADSM servers from
>the default (16) to 32.
><----  End Forwarded Message  ---->
>
>
>I haven't done a thorough analysis of the best combinations of these values, 
>but
>I set the txngroupmax setting on the server to 256 (max number of files in a
>transaction) and the txnbytelimit setting on the client to 25600 (max number of
>KB in a transaction) and found that it did indeed make an improvement,
>especially for smaller files.
>
>Andy Raibeck

I also have set txngroupmax to 256 on the server but I haven't distributed
new version 2 clients yet, so txnbytelimit is still at the default.  I plan to
set it to 2048 or less.

I have seen one problem with going very high on txnbytelimit during testing
and that is with
compression.  If a file grows during compression, it appears that the whole
transaction is rolled back, the files already sent are resent uncompressed, and
then the offending file.  If poor compressing files are properly sprinkled
thru a file system, you could see much worse total thruput with these
parameters set up high.

There is a client option called 'compressalways' which says ignore growth
during compression, but unfortunately it is only for API clients!  I have
asked IBM to make it available for all clients.

Bill Colwell
C. S. Draper Lab
Email: BColwell AT draper DOT com
Voice: 617-258-1550