ESIX Networks and X

wingard at Columbia.NCR.COM wingard at Columbia.NCR.COM
Sat Dec 16 06:12:22 AEST 1989


In article <951 at fiver.UUCP> palowoda at fiver.UUCP (Bob Palowoda) writes:
>
>  Some more detailed questions are:
>
>  How does NUMTIM affect streams efficacy?

It sets the number of "timod" STREAMS modules (which implement TLI
endpoint support) available in the system.  For implementations of
X11 or TCP/IP based on TLI, it is one of the limiting factors on the
maximum number of simultaneous X or TCP/IP connections (since you have
to have a timod for every connection).

>
>  What factors come in when setting the number of NBK sizes?
>

Basically, the total volume of STREAMS traffic you expect.  My experience
has been that 4, 16, and 64 byte buffers are the ones you need most of.
The amount of memory you have is a factor also -- it's nice to have huge
pools of buffers waiting around, but not you if get a huge kernel that
makes all your programs swap for lack of available space.  I can't give
give you accurate sample numbers, 'cause it might be an apples and oranges
comparison -- I administer an NCR Tower 32/825 with 3 processors with
16 MB apiece, supporting 10 users and 30+ xterm sessions (and all the
xclock's, etc. that they like to run) running on X terminals over TCP/IP.
This is an excerpt from one of our STREAMS utilization reports (the
numbers are large because this kernel's been running for about a month):

Item        In Use     Free      Total      Max   Config   Failed
-----------------------------------------------------------------
Streams:       198      618     299750      229      816       0
Queues:       1160     3202     609555      679     4362       0
NBLK4:          82      282    8996206      328      364    3307    ****
NBLK16:          0      428   12017790      343      428    1108    ****
NBLK64:        101      347   64584846      230      448       0
NBLK128:         7      185    5618815      176      192       9    ****
NBLK256:        92       68     707440      160      160      26    ****
NBLK512:        10       90     823046       48      100       0
NBLK1024:        5       63     266254       16       68       0
NBLK2048:        5       79      78489       17       84       0
NBLK4096:        0        6       2551        5        6       1
Mblocks:       302     2010  102707074     1213     2312       0
Dblocks:       302     1548   93095437      895     1850    4451

As you can see, I've still got to go in and bump up the allocations
marked with asterisks to handle our peak load.  In cases of severe
data block starvation, you won't see any messages or warnings --
you'll just see things slow down severely or just "freeze"; some
drivers that need a STREAMS block badly will just sleep until they can
get one (yecch).  The best tool for this is the "strstat" command in
crash.  You get reports like the one above that you can use to determine
if you've allocated enough resources.

>
>  What does increaseing the number of NQUEUE's do with respect
>  to a single user and multiusers? 

Every STREAM is implemented by a series of queues.  Consequently,
increasing NQUEUE (in tandem with NSTREAM) gives you more available
STREAMS.  This is important if you've got a bunch of users doing
STREAMS stuff, or if you're one user doing a bunch of STREAMS stuff.
The "proper" ratio of NQUEUE/NSTREAM depends on the typical "height"
of your STREAMS stacks; i.e., how many modules do you usually have
PUSHed on a STREAM between the driver and the STREAM head?

>
>  What streams tuneable factors take more effect for a single user 
>  useing Xwindows or a network as opposed to multiple users?
>

Assuming that you're using the AT&T-styled XWIN that makes all X server
communication over TLI & STREAMS whether you're local or remote, it's
all a matter of degree.  The STREAMS subsystem acts the same way whether
it's handling one user or ten -- you've just got to make sure that you
allocate resources proportionally to the number of users you expect and
the amount of traffic they're going to generate.  Remember that along
with NQUEUE, NSTREAM, and the NBLK parameters, you may need to increase
parameters like NUMTIM (as explained above), NUMTRW (for TLI connections
that expect a read(2)/write(2) interface instead of t_snd and t_recv),
and allocations for other STREAMS modules such as "ldterm", "ptem" and
the STREAMS pseudo-tty drivers.

Hope that this helps -- sorry if I got a little long-winded.


--
Steve Wingard				wingard at ncrcae.Columbia.NCR.COM
NCR Corporation, E&M-Columbia		gatech!ncrats!ncrcae!wingard
#include <disclaimer.h>			hp-sdd!ncr-sd!ncrcae!wingard



More information about the Comp.unix.i386 mailing list