Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!ncrlnk!ncrcae!sauron!wingard From: wingard@Columbia.NCR.COM Newsgroups: comp.unix.i386 Subject: Re: ESIX Networks and X Message-ID: <1846@sauron.Columbia.NCR.COM> Date: 15 Dec 89 19:12:22 GMT References: <453@everex.UUCP> <951@fiver.UUCP> Sender: news@sauron.Columbia.NCR.COM Reply-To: wingard@ncrcae.Columbia.NCR.COM Organization: NCR Corp. E&M-Columbia, W. Columbia, SC Lines: 89 In article <951@fiver.UUCP> palowoda@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@ncrcae.Columbia.NCR.COM NCR Corporation, E&M-Columbia gatech!ncrats!ncrcae!wingard #include hp-sdd!ncr-sd!ncrcae!wingard