Andy,
        On the Netware servers you might want to check the MAXIMUM PHYSICAL =
RECEIVE PACKET SIZE.  This is could be your bottleneck.  Your TCP =
packets will have to fit inside of this.  The MTU will be negotiated =
when the connection is initiated.  The device with the smallest MTU will =
define the communications parameters.  I would look first at you Netware =
servers (or whatever ADSM clients you are using), then at the interfaces =
on any routers between your ADSM clients and the ADSM server, and =
finally at your ADSM server.  I know you can set the MAXIMUM PHYSICAL =
RECEIVE PACKET SIZE on a Netware 3.11 server to anything between 618 and =
4202 and on a Netware 3.12 server to anything between 618 and 24682.  I =
think the default for the Netware 3.11 server is 1514 (typical for =
Ethernet) and the default for the Netware 3.12 server is 4202.  =
Depending on how your Netware clients are using the Netware server, you =
may be able to bump this up considerably.  You may want to be cognizant =
of the impact on your Netware users though.  If, for example, you set =
MAXIMUM PHYSICAL RECEIVE PACKET SIZE to a VERY large number then when =
your Netware users log in it may take a little longer to negotiate the =
MTU if they are traversing a large number of routers.  This will have =
little to no consequence if the users are logging in and staying =
connected.  (It may be relevant though if the users are CONSTANTLY =
logging in and out.)

        You may also want to look at the MINIMUM PACKET RECEIVE BUFFERS and =
MAXIMUM PACKET RECEIVE BUFFERS parameters on the Netware servers.  This =
could potential have an effect on performance.  A note of warning =
though:  As you increase MINIMUM PACKET RECEIVE BUFFERS you will =
increase memory usage on the server and I have heard that if you current =
PACKET RECEIVE BUFFERS as listed in MONITOR ever attempts to exceed the =
MAXIMUM PACKET RECEIVE BUFFERS the server will crash.  ( I have never =
seen it happen, just heard a rumor. )

Let me know what you find out.

Thanks,
Jay Strickland
JSTRICKL AT IPCTECH DOT COM                                                    
=09