NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/vmsnet/vmsposi/88

Text File | 1992-12-22 | 3.4 KB | 73 lines

Newsgroups: vmsnet.vms-posix
Path: sparky!uunet!cs.utexas.edu!swrinde!sdd.hp.com!elroy.jpl.nasa.gov!ames!tgv.com!adelman
From: [e-mail] (Kenneth Adelman)
Subject: Re: TWO items perhaps of interest...
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: NASA Ames Research Center, Moffett Field, CA
X-Lunar-Date: 4 days, 2 hours, 43 minutes since the last quarter of the moon
Date: Tue, 22 Dec 1992 22:28:00 GMT
Lines: 61

    Someone recently pointed out to be a post from Brent Sterner
on December 8th detailing a potential interference between MultiNet
and Posix use of SPTREQ. Brent said:

    There is a potential interference between POSIX and TGV
    MultiNet's usage of SPTREQ pages [...]. [...] Suffice to
    say that POSIX release notes indicates that it needs 1000
    pages more, and MultiNet also uses this resource for
    buffer space somehow, and we have to patch MultiNet to
    provide it with more buffer space and bump SPTREQ by
    1024 to accomodate MultiNet's needs.

    The symptoms we saw were failure of existing MultiNet
    connections and MultiNet diagnostics on the console indicating
    that it had ran out of buffer space. The MultiNet command
    SHOW BUF indicated:

        xxx out of yyy buffers in use:

    where yyyy was reaching ~1290 and xxx was pushing yyyy.


    This isn't really an full description of the problem, nor does
the problem have anything to do with POSIX.  MultiNet uses system page
tables to allocate address space to use for loading code and for data
buffering.  In a normal configuration, MultiNet will use approximately
1700 SPTs for code+data.  If 1700 are not available, it will reduce
the amount of buffering from the default, and try again until it can
allocate enough SPTs.  Both MultiNet and POSIX use SPTs, so it is
important to add the two requirements together when tuning your
system, eg, 1700 for MultiNet plus 1000 for POSIX means you need 2700.

    There are two potential problems with SPT usage in MultiNet, but
they are more correctly diagnosed by using $ MULTINET SHOW/BUF and
looking for a line of the form "xxx requests for memory denied".  If
this line does not appear, your machine is healthy, EVEN if "xxx out
of yyy buffers in use" indicates that almost all of your buffers are
being used.  Only the virtual address space for buffers are allocated
from SPTs; the actual pages of memory will not be filled in until
needed.  It is normal for a machine to have "xxx" near "yyy"; "xxx" is
the current buffer usage and "yyy" is the peak.

    1) The customer doesn't have enough SPTREQ (that is, didn't
       raise it by 1700 when he installed MutliNet) left when
       MultiNet starts.  MultiNet will start with a reduced amount of
       virtual address space for buffering, but customer doesn't
       notice the OPCOM message.  This can be diagnosed by: $ multinet
       set/kernel nmbclusters and be sure you get back a value of 256.

    or

    2) The customer has a configuration that requires more than the
       512KB maximum buffering hardcoded into MultiNet.  This is
       unusual, but was indeed Brent's problem.  In this case, we'll
       step the customer through patching MultiNet to increase the
       amount of buffering, which REQUIRES a corresponding increase in
       the SYSGEN parameter SPTREQ. MultiNet V3.2 will allow the
       customer to configure the buffering space without patching
       the kernel.

                            Ken