[comp.sys.apollo] 10.3 RC TCP after NCS services?

waldram@WOLF.UWYO.EDU (01/05/91)

On our DN10000 running SR10.3, we run tcpd, llbd, glbd, and rgyd.  We have had two
occasions where rgyd (a slave) has started utilizing 80%+ of the cpu (dspst).
It has been suggested that if tcpd "blinks" it loses its socket to one of the NCS 
services daemons, but continues to run.  When tcp services are requested, the 
lost socket is under contention.  I do not understand these details.  A suggestion
of starting TCP services (rc.local) after NCS services (just before cron in /etc/rc)
may cure the problem, but may cause other MAJOR problems related to the local site
network setup.  Has anyone:
   1) tried the order switch?
   2) seen more detail on when the switch is safe?
Explanations of the "fuzzy" description/activity above would be appreciated.
           thanks,
               -jjw
Jim Waldram
University of Wyoming
waldram@grizzly.uwyo.edu
jwaldram@outlaw.uwyo.edu
jwaldram@UWYO.BITNET

bep@quintro.uucp (Bryan Province) (01/08/91)

In article <9101042351.AA05130@wolf.Uwyo.EDU> waldram@WOLF.UWYO.EDU writes:
>On our DN10000 running SR10.3, we run tcpd, llbd, glbd, and rgyd.  We have had two
>occasions where rgyd (a slave) has started utilizing 80%+ of the cpu (dspst).
>It has been suggested that if tcpd "blinks" it loses its socket to one of the NCS 
>services daemons, but continues to run.  When tcp services are requested, the 
>lost socket is under contention.  I do not understand these details.  A suggestion
>of starting TCP services (rc.local) after NCS services (just before cron in /etc/rc)
>may cure the problem, but may cause other MAJOR problems related to the local site
>network setup.  Has anyone:
>   1) tried the order switch?
>   2) seen more detail on when the switch is safe?
>Explanations of the "fuzzy" description/activity above would be appreciated.
>           thanks,
>               -jjw
>Jim Waldram
>University of Wyoming
>waldram@grizzly.uwyo.edu
>jwaldram@outlaw.uwyo.edu
>jwaldram@UWYO.BITNET

This may or may not be what you're looking for but we recently found a
version problem with our rgyd.  We had upgraded our master registry node to
10.2 but for some reason the /etc/rgyd was not updated (possibly because it
was locked during the install but that shouldn't make a difference).  In any
case we were running the 10.1 rgyd on a 10.2 node in a mixed 10.1 and 10.2
network.  I recopied the file, rebooted the node and we've been fat, dumb,
and happy ever since.  Try the following command on your networks:

ts //*/etc/rgyd

The version we are running in our 10.1, 10.2, 10.3 network is this:

o 3 rs_c              1989/10/06  8:22:41 CST (Fri)  /etc/rgyd

-- 
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
Bryan Province -Glenayre Corp., Quincy, IL- quintro!bep@lll-winken.llnl.gov
             "I tried putting instant coffee in the microwave,
                I almost went back in time."  - Steven Write