> Date:    Mon, 16 Feb 1998 14:10:36 -0500
> From:    "Prather, Wanda" <PrathW1 AT CENTRAL.SSD.JHUAPL DOT EDU>
> Subject: Re: NT Client Stops Fileserving During Backup
>
> When you say "kill ADSM", I assume you mean kill the scheduler service
> on the client?
>
I mean cancel the backup client.  I am not running the scheduler.

> Our ADSM server is V2 on AIX.
> We run about 200 WinNT & Win95 desktops, about 40 AIX servers and 30
> WinNT 4.0 servers as ADSM clients.
> Of the WInNT 4.0 servers, some are fileservers only, most operate as
> file servers AND run other stuff as well.
> Some are as slow as 100mz, most are between 100-200mz.  We run with
> COMPRESS ON on all of them (i.e., the client does the compression before
> sending data.)
> I have never encountered a problem like you describe.  Our network is 16
> MB token ring.  With COMPRESSION ON, the backup speed is always limited
> by the processor speed of the client machine, but we can do a lot better
> than 500K per hour on the faster NT machines.

This machine is a PP200 with 128MB memory running a RAID-5 Adaptec filesystem
using an array of 9GB Barracuda drives.  It's about 45GB now.  The transfer
rate sits at around 500K, it's on a 100Mbit TCP/IP network, which I suspect
is the problem, micro$oft TCP/IP is pretty bad.
>
> When you get weirdness like that with the 32bit Windows client, I
> usually resort to a piecemeal debugging approach.
> Some things you could try:
> -       Load the V2 client instead of the V3 client and see if you get
> the same results.  That would rule out a performance problem introduced
> with V3.

This isn't really practical now, we are in a pure V3 environment on these
machines.

> -       Turn off COMPRESSION, and/or try SLOWINCREMENTAL in the client
> options file.  If you are having a serious CPU problem, or a memory
> problem, that should help.

I don't think it's a CPU problem because everything looks pretty normal
on the NT console, it's just that all fileserving comes to a halt and it
can't service it's other obligations on the network.  I SLOWINCR safe,
or does it cause large backup jobs to run out of resources and crash?

> -       Use the GUI and try running an incremental backup on one drive
> at a time.  If there is a problem in the client file system, sometimes
> you can find it that way.

It is one drive at this time, albeit a very large one.  Thanks for your 
response.
>
> Good luck!
>
>
> ===============================================================
> Wanda Prather
> Johns Hopkins Applied Physics Lab
> 443-778-8769
> wanda_prather AT jhuapl DOT edu
>
> "Intelligence has much less practical application than you'd think."
>               - Scott Adams/Dilbert
> ===============================================================
>
>
>
>
> > ----------
> > From:         Mitch Sako[SMTP:mitch AT cellnet DOT com]
> > Sent:         Friday, February 13, 1998 5:47 PM
> > To:   ADSM-L AT vm.marist DOT edu
> > Subject:      NT Client Stops Fileserving During Backup
> >
> > We have two PP-200/128MB NT4 machines.  The ADSM server is running
> > fine, TCP/IP, ADSM Version 3 server and client.  A fileserver running
> > a ADSM V3 client seems to stop fileserving when the backup client
> > is pumping data out the pipe.  It's a 100Mb pipe (NT seems not to be
> > able to drive much traffic over it, anyway using TCP/IP, though) but
> > it's getting 500KB+ for most of the transfer.
> >
> > When fileserving stops, clients on the domain freeze when accessing
> > the fileserver, kill ADSM and the problem goes away.
> >
> > Is NT so primitive that it can't scratch and chew gum at the
> > same time?
> >
> > Is ADSM on NT such a hog that it takes over a machine even though all
> > the related resource allocation dials have been screwed down tight?
> >
> > I've read the the NT TCP/IP stack is one of the suckiest
> > implementations
> > of TCP/IP on earth, does this mean we are doomed until micro$oft
> > decides
> > to do something about this?
> >
> > Our UNIX client(s) do not seem to have this problem, nor does the
> > ADSM server running on NT seem to have any performance problems.  It's
> > just the ADSM NT client that has the problem.
-------------------------------------------------------------------
Mitch Sako                            Phone:     650.508.6761
Mitch Sako                            Phone:     650.508.6761
Cellnet Data Systems                  FAX:       650.508.6700
125 Shoreway Road                     Pager:     408.989.3365
San Carlos, CA 94070                  E-Mail:    mitch AT cellnet DOT com
                                      Personal:  msako AT netcom DOT com