Bill,
     I've been experimenting with the TXNGROUPMAX and TXNBYTELIMIT
parameters... does seem to help except when you have compression enabled on
the client.  If compression is enabled and ADSM runs into a file that
'grows' when compressed, it resends all the files for that transaction.  Can
be a hassle if you're sending 256 files at a clip and the 255th file is the
one that 'grows' when compressed.  Would be nice if there were an option in
ADSM to tell it to send the file anyway, even if it grows (think you can do
that with the API).  Have you noticed the same thing in your testing ???

Tim Pittson
 ----------
From: owner-adsm-l
To: Multiple recipients of list ADSM-L
Subject: Re: ADSM Througputs
Date: Thursday, February 15, 1996 7:50PM

In <bitnet.adsm-l%m0tn7SQ-000TMZC@hlc>, mduhaime AT ibmir DOT com (Mike Duhaime)
writes
:
>Regarding throughput, our experience has been that one of the most
>signifigant rate limiting factors is the processing power of the client and
>its ability to put data on the network.  What are your clients?  Alot of
>these questions seem to be related to Novel environments where there likely
>to be older machines.  Without knowing the clients, it might be a gross
>assumption, but slow clients will kill your throughput and there is no way
>to go faster.
>
>>There has been much discussion recently about ADSM throughput.  I
 (snip...)
>>much.
>>
>>------------------------------------------------------------------
>>Robert P. Klein                          KL2 AT CU.NIH DOT GOV
>>Phone: 301-496-7400                      Fax: 301-496-6905
>>Mail:  DCRT/CFB/ETS, 12A/1033, 12 SOUTH DR MSC 5607,
>>       BETHESDA, MD 20892-5607
>>------------------------------------------------------------------
>>
>>


There are 2 options which may provide some improvement especially for
small files.  The options are in V2 and in later releases of V1.

On the server, TXNGROUPMAX says how many files to receive before doing
a database commit.  It default to 10. The option lets you raise it to
256.  On the client, TXNBYTELIMIT says how many kilobytes the client
should send before it asks the server to commit.  It defaults to 340.
The option can raise it to 25,600.

Database commits are expensive and they might also 'drain the pipe'.  I have
done a little testing but have not yet distributed the clients widely.
It has helped with small files.  Has anyone else used this feature widely
yet?

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