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