don@dons3b1.UUCP (Don Joslyn) (12/17/88)
Expert Tuners,
I have some questions regarding UNIX-PC system tuning:
1. Can the sticky bit be used to make loading programs faster on
the UNIX-PC? If yes, what programs have you set the sticky bit
on? Any comments?
2. I have 2 meg of memory. What can I change in /etc/master to
increase disk performance? How did it help your system
performance?
3. Should I add -s to the fsck command in /etc/rc to sort the free
list? If yes, why should I?
Any helpful hints would be appreciated. Thanks in advance,
P.S. UA is already a goner. If and when I need it, I can execute it like
any other command. :-)
Don Joslyn
Cooper City, Florida
UUCP: ...{uflorida,ucf-cs}!novavax!dons3b1!dontkacik@rphroy.UUCP (Tom Tkacik) (12/19/88)
In article <19@dons3b1.UUCP> don@dons3b1.UUCP (Don Joslyn) writes: > I have some questions regarding UNIX-PC system tuning: > 1. Can the sticky bit be used to make loading programs faster on > the UNIX-PC? If yes, what programs have you set the sticky bit > on? Any comments? > I tried using the sticky bit on vi at one time, and found that there was no decrease in load time at all. I came to the conclusion that the sticky bit did not work on the Unix-PC. That was with 1Meg of memory. I now have 2.5Meg, and recently tried it again. This time I found that the load time for vi went from about 5 seconds to about 2. I have been running gdb (the GNU debugger), which has an executable of about 150K. This seemed to take forever to load, about 11 seconds. Setting the sticky bit brought it down to under 4 sec. Currently I also have the sticky bit set on the GCC-cc1, about 400K, and the spreadsheet sc, 120K. All have had load times drop by less than half. This is just a test to see how much the sticky bit helps. I will probably change which programs I use it on later. Programs I use frequntly. If you have enough memory, it helps a lot. If you only have 1Meg, (or less), there seems to be very little difference. As to which programs to set the sticky bit on, I don't have enough experience to say, and would also like to know a good answer. My best guess it that they be those few (number depending on how much memory you have) programs that you use very frequently, and are large (>100K). Vi is a good first choice. (Unless of course you use emacs, in which case that is an even better first choice due to its size :-). --- Tom Tkacik GM Research Labs, Warren MI 48090 uunet!umix!rphroy!megatron!tkacik
jay@banzai.UUCP (Jay Schuster) (12/21/88)
In article <6412@rphroy.UUCP> tkacik@rphroy.UUCP (Tom Tkacik) writes: >I tried using the sticky bit on vi at one time, and found that there was >no decrease in load time at all. I came to the conclusion that the sticky bit >did not work on the Unix-PC. That was with 1Meg of memory. I now have 2.5Meg, >and recently tried it again. This time I found that the load time for vi >went from about 5 seconds to about 2. I have been running gdb (the GNU >debugger), which has an executable of about 150K. This seemed to take forever >to load, about 11 seconds. Setting the sticky bit brought it down to under >4 sec. Currently I also have the sticky bit set on the GCC-cc1, about 400K, >and the spreadsheet sc, 120K. All have had load times drop by less than half. > The sticky bit makes the program be loaded off of the swapper instead of from the filesystem. Since vi is part of the installed original set (most likely), grabbing it off of probably sequentially allocated blocks off of the filesystem versus getting it off of the definitely sequentially allocated blocks of the swapper isn't so much of a win. If your filesystem is fragmented, which it probably is when you end up installing huge things like gcc and gdb, then setting the sticky bit has the effect of `moving' the fragmented file into an unfragmented space, increasing load speed. -- Jay Schuster uunet!uvm-gen!banzai!jay The People's Computer Company `Revolutionary Programming'
jbm@uncle.UUCP (John B. Milton) (12/22/88)
In article <19@dons3b1.UUCP> don@dons3b1.UUCP (Don Joslyn) writes: ... > 1. Can the sticky bit be used to make loading programs faster on > the UNIX-PC? If yes, what programs have you set the sticky bit > on? Any comments? If you have LOTS of memory, and low system usage, yes. > 2. I have 2 meg of memory. What can I change in /etc/master to > increase disk performance? How did it help your system > performance? You can anything you want in /etc/master, and it will NOT increase you disk performance. This weirdo UNIX AT&T put on this machine is not supplied with the normal .o files and libraries to re-link the kernel to re-configure it. The re-configuration is limited to the parameters that can be poked at with the ktune(7) command. All you can change is: nbuf, ninode, nfile, nproc, ntext, nclist, npbuf, ncall and nttyhog. It does this by patching a ktune struct in the kernel. The kernel uses these values as the "desired" value the next time it boots. > 3. Should I add -s to the fsck command in /etc/rc to sort the free > list? If yes, why should I? This one is very clumsy on a one drive, one partition machine, but it could be done easily at boot-up time in /etc/rc. John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu (614) h:294-4823, w:764-2933; Got any good 74LS503 circuits?
jcm@mtunb.ATT.COM (was-John McMillan) (12/23/88)
In article <449@uncle.UUCP> jbm@uncle.UUCP (John B. Milton) writes: >In article <19@dons3b1.UUCP> don@dons3b1.UUCP (Don Joslyn) writes: >... >> 1. Can the sticky bit be used to make loading programs faster on >> the UNIX-PC? If yes, what programs have you set the sticky bit >> on? Any comments? >If you have LOTS of memory, and low system usage, yes. Please enlighten me: "LOTS of memory"... usually refers to RAM. But... to my recollection, the cost of the Sticky bit is a few dozen bytes -- specifically, ONE text-table entry. OK: in the larger sense DISK SPACE is called "extended memory", "secondary memory", or other such goodies. Punch cards might also be. In MY phantasy, the Sticky bit just locks a shared-TEXT image onto the swapping disk. Ergo, you will run out of SWAP SPACE if you're overly sticky or under-equipped. (Of course, our beloved operating system, unable to allocate SWAP SPACE, during an EXEC [or fork?] responds with "ENOMEM"... but it probably does that if you run out of punch cards, too... ;^) "Low system usage?" Mine remains at desk height because of nose-bleeds. Again: if you're tying up the SWAP with Sticky Bits, it ain't there for other use. Running LOTS of programs (pardon the hi-tech talk) may run ya out of swap space. So can ONE program if you're into Grand-MALLOC seizures and bit-graphix. My VI starts in 3 seconds, thus staying within the speed limits and satisfying my primal urges. It WILL start in ~1 second if I pour honey over it. ...@ a cost of 100KB of swap. Few programs have as bulky a TEXT portion and few therefore benefit this greatly. (NB: ONLY TEXT can be locked on SWAP by Stickiness, DATA must be demand paged.) Those who benefit MOST are those with the slowest disks -- who are usually those with the smallest disks and least SWAP space. __________ <- The bottom line: BATHE OFTEN... and don't get any stickier than you MUST. >> 2. I have 2 meg of memory. What can I change in /etc/master to >> increase disk performance? How did it help your system >> performance? >You can anything you want in /etc/master, and it will NOT increase you disk >performance. This weirdo UNIX AT&T put on this machine is not supplied with >the normal .o files and libraries to re-link the kernel to re-configure it. >The re-configuration is limited to the parameters that can be poked at with the >ktune(7) command. All you can change is: nbuf, ninode, nfile, nproc, ntext, >nclist, npbuf, ncall and nttyhog. It does this by patching a ktune struct in >the kernel. The kernel uses these values as the "desired" value the next time >it boots. This "weirdo" system was spec'd to run with only .5 MB RAM and a 10 MB disk. (NO-- it wasn't the greatest COMPILATION-Machine with this hardware ;-( ) You DON'T put .o's on a system with a 10 MB disk. CORRECTION: I DON'T, perhaps others do. Was it a bad original decision? Do companies ever mis-estimate markets ;^? OK, ya wanna improve DISK performance? Clearly you can 1) try to reduce DISK ACCESSES a) By increasing NBUF from 100 to around 120. I doubt it's worth it, as it may increase PAGING. b) By decreasing PAGING by adding RAM (or decreasing page-contention -- ie., decreasing Program size, skipping UA, or maybe DECREASING NBUF!) Rough recollections: a BASIC 1 MB system is already "consuming" ~1.2 MB RAM by the time UA has spawned a single KSH. About 500KB of this is PAGED-OUT -- but some will flush through with each window change, "smgr" update, or background/daemon activity. The kernel will attempt to keep 200KB available/free/un-attached -- to permit reasonably fast forks & exec's. The system will become claustrophobic with less than 64KB free space. _________ <- Re-lining your bottom: if, with 2 MB RAM, you have tasks ACTIVELY accessing more than (around) 1.2MB "at once", you're a candidate for more RAM. (Or if you have tasks locking up great-green-gobs of SHARED-MEMORY, which is LOCKED IN RAM.) CAVEAT: The above paragraph is backed by my hallucinations, not by a specific study of the issue. 2) get a faster disk. The "1b)" wins if you're thrashing and "2)" wins if you've a slow disk. >> 3. Should I add -s to the fsck command in /etc/rc to sort the free >> list? If yes, why should I? >This one is very clumsy on a one drive, one partition machine, but it could >be done easily at boot-up time in /etc/rc. I do it on most of the machine's I control, but I'm a noted masochist (or I wouldn't be writing this ;<) It IS easier on multi-partition systems and on a full stomach. You are making a REASONABLE inquiry whose answer chains through many more concepts than I care to stumble through. Regular FSCK-ing is but ONE in a number of steps that CAN SOMETIMES yield improvements but which may well waste your time. It MAY provide a more orderly disk free-list which MAY produce a higher sequential-access rate when sequentially re-reading files. It also increases cylinder co-residence of program blocks and therefore reduces seek-times during demand-paging. More than enuff said. Sorry to bore ya. Off to a flame-free vacation. JC McMillan -- att!mtunb!jcm -- Speaking only for hizzelf. (& 2 tired 2 proofread this.)