Thanks for that info. I tried both of those settings at the same time and
it seems to have helped.  I will do some more testing but will probably
keep both settings even if only one is helping the WAN speed.  The
DISKBUFFSIZE can be set as high as 1023.  (those are only kbytes).  Is
there any reason to avoid the max?

Tom


>>-DISKBuffsize-- --*size*---------------------------------------><
Parameters[image: Windows operating systems] WINDOWS sizeSpecifies the
maximum disk I/O buffer size (in kilobytes) that the client uses when
reading files. The range of values is 16 through 1023; the default is 32.

On Thu, Feb 18, 2016 at 2:30 PM, Hans Christian Riksheim <bullhcr AT gmail DOT 
com>
wrote:

> I have had luck with setting tcpwindowsize 0 on server and client and
> letting the OS handle it.
> Also diskbuffsize 512.
>
> Hans Chr.
>
> On Thu, Feb 18, 2016 at 8:15 PM, Skylar Thompson <skylar2 AT u.washington DOT 
> edu
> >
> wrote:
>
> > I thought TCPBUFFSIZE could only go up to 64? It could be that setting it
> > to 512 actually sets it to the default of 16.
> >
> > On Thu, Feb 18, 2016 at 02:03:26PM -0500, Tom Alverson wrote:
> > > I am seeing very poor WAN performance on all of my (wan based) TSM
> > > backups.  Due to the latency (40 msec typical) I normally only get
> about
> > > 20% of the available bandwidth used by a TSM backup.  With EMC
> Networker
> > I
> > > get over 90% utilization.  I have already set all of these recommended
> > > options:
> > >
> > > RESOURCEUTILIZATION 2
> > >
> > > TXNBYTELIMIT 2097152
> > >
> > > TCPNODELAY YES
> > >
> > > TCPBUFFSIZE 512
> > >
> > > TCPWINDOWSIZE 2048
> > >
> > > LARGECOMMBUFFERS YES
> > >
> > >
> > > Does anyone know of anything else that could help performance?  Has
> > anyone
> > > used a Riverbed accelerator for TSM backups?
> > >
> > >
> > > Tom
> >
> > --
> > -- Skylar Thompson (skylar2 AT u.washington DOT edu)
> > -- Genome Sciences Department, System Administrator
> > -- Foege Building S046, (206)-685-7354
> > -- University of Washington School of Medicine
> >
>