Jeff,

Many thanks to you and Ian Northeast for the help on this switch tuning problem.
As Ian suggested, I'll change the css0 buffer sizes first. If I get enough time
to experiment, I'll change 'no' settings, too. We'll find out next week, when I
can take the SP down, what kind of a difference it makes.

By the way, if anyone's interested, we finally got all of our standalone
RS6000s, mostly J40s, running backups across 155 Mb ATM to the ADSM server on
the SP high node. The backup times dropped to about one third of what they were
across ethernet. They're also about the same as the backup times for the switch.
Just wanted to pass that on.

Jim Bootz
bootz AT adc DOT com

>
> In message <9703312039.AA11119 AT alssun.adc DOT com>, Jim Bootz
> <bootz AT ADC DOT COM> writes
> >Recently, we attempted for the first time to do parallel backups to three
3590
>
> >tape drives in a 3494 robotic library across an SP switch and failed with
> >numerous "TCP/IP connection" failures. Similar parallel backups across
> ethernet
> >worked fine, but were much slower than a switch. We also had success using
> just
> >two drives and the SP switch. Has anyone else had this experience? Is this a
> >matter of tuning (our 'no' settings are considered optimal according to the
> >latest information on SP tuning)? Or, are we expecting too much?
>
> We had the same problem and contacted the support center.  Apparently the
> device driver for the SP switch (TB3), not the High Performance switch (TB2),
> now does it's own buffer handling.  If the buffer size is too low then ADSM
> suffers from time-out problems when backing up across the switch.  Raising
> the buffer size fixed our problems.
>
> To check the buffer size issue the command: lsattr -E -l css0
> and check the values for "spoolsize" and "rpoolsize".  These specify the
number
> of bytes to allocate for send and receive pools.  These values default to
512K.
> The support center recommended values of 10M to 15M for ADSM backups.
>
> We set our spoolsize and rpoolsize to 10M each this past weekend and ADSM is
> now running fat, dumb, and happy.
>
> You change the values using this command:
> /usr/lpp/ssp/css/chgcss -l css0 -a spoolsize=10485760 -a rpoolsize=10485760
>
> (this is the command we used to change the pools to 10M)
>
> There are some caveats, though.  First, the spoolsize and rpoolsize values
> MUST be the same on all nodes using the switch.  Apparently during an Estart
> there is some hand-shaking between the adapters and the lowest values for
> spoolsize and rpoolsize get propagated to all the nodes.  Second, since the
> the buffers are at the device driver level, and are only obtained at boot
time,
> a reboot of all the nodes is required to change spoolsize and rpoolsize.
>
> Hope this helps.
>
> Jeff Renicker
> IBM GLobal Services
> e-mail: jrenicker AT vnet.ibm DOT com
> voice: (330) 796-3984