Conference decwet::networker

509.0. "NSR4.2b and DU4.0b Slow ?" by ACISS2::CAMP () Wed Mar 19 1997 22:09

    I am working with a customer who has recently upgraded their Digital
    Unix systems from DU 3.2g to 4.0b.  NSR backups are now running at
    displayed rates of 100 to 300k /sec.  These same backups used to run at
    displayed rates of 1-4g /sec.  
    The systems are several A255 workstations, A2000s, A2100s, and an 8400
    and 2100a in a v1.4 Available Server (ASE) configuration.
    The upgrade sequence started with the sytems running 3.2g, nsr v4.2b,
    and patch 1. Nsr was removed leaving the files and dir (default answer
    to ?s)  Unix was then upgraded to 4.0a then 4.0b.  Unix patch release
    of Feb 27 was then installed.  Now nsr v4.2b was installed and patches
    in the range of 1-9 were installed.  Results - backups were slow.
    We have tried: Installing 4.0b clean with no patches, installing nsr
    clean (removing files and directories during removal), and various
    numbers of the nsr patches, and pulling our hair out. - no improvement.
    Tape drives are tz87s, tz88s, and a tz877.  Servers get higher speeds,
    600-900k/sec when backing up clients.  Same servers get speeds of
    100-300k when backing up themselves.  Clients which got above rates
    going to servers get rates of 100-300k when backing up themselves.
    We have tried increasing parrellelizm ect.  Vdumps run at good
    rates, 2.2-2.5g /sec.
    After installing the patches several times I have learned that the 4.0
    and above client files are in decpt directories and 3.2 client files
    are in decaxp directories.  These clients always refer to arch decaxp
    in the details window.  We have tried setting them to decpt in the GUI
    and it goes away despite accepting the change.  We have hacked the res
    file to be arch of decpt and still no improvement.  They also appear
    as decaxp on fresh installs.  The whole point of arch may be irrelevant 
    this is just an observance.
    Any help would be appreciated.
    Keith Camp

We have an open IPMT from a customer who has the same problem.  
While we don't have an answer yet, I do know that "arch" should 
be "decaxp".  The "decaxp" vs. "decpt" is just a kitting feature 
to keep the binaries straight.

Wes