yeh@cs.purdue.EDU (Wei Jen Yeh) (03/11/91)
Hello,
I believe somebody must have been in the same situation -- How to upgrade
your system?
This is my situation. I'm running Dell's 4.0 on a 386-20. It has 8mb of
memory, and does not have cache or a 387. I usually work under X and have
three to four xterms opened. The system gets REALLY SLOW when a compilation
is taking place. It gets even worse when lisp is running. You can count the
characters when they are displayed on the screen! So, the question is,
how do I upgrade my system? A faster machine, more memory, or a math-co?
I understand that 387 will improve the X performance (at leaset for Dell's
stock X11R4). (That brings up another question. Is Roell's port of X11R4
fast enough w/o a 387? I heard that Dell is going to release a version of
Roell's X386 for their 4.0) But which option will give me more improvements?
A related question is how do I determine the current bottleneck of my
system? How does one read the results from sar, and which values are the
important ones? Which kernel parameters should I try to modify first?
I appreciate any help/info you can give me.
The next questions are for people running Dell 4.0 and have used any comm.
program under it. I use kermit to connect to the computer at school with a
2400 baud modem. When doing a long cat on the remote host, the local m/c
will split out about 20-30 lines of text with intermittent stops, then the
rest of the output is not displayed. The connection is still there. It looks
like the async input buffer was full and the input handler just ignored the
incoming characters without blocking the sender. Has anyone seen this problem?
BTW, this occured under both X and the ascii console.
Another question. A quit (ctrl-C) when executing some programs
causes ksh to dump core. A reproducible example is the command
"zcat gcc-1.39.tar | tar tvf -". ksh prints the messages after ctrl-C is
pressed:
ksh: 24235 Quit(coredump)
ksh: 24234 Quit(coredump)
, where the two integers are pid's.
I reported both problems to support@dell, but have not gotten any denial or
confirmation of them.
BTW, I successfully established a 3.2 devp. environment under 4.0 using
gcc. It's really simple once you figure out how to modify the various
SPEC definitions in the tm-i386*.h file.
Thanks in advance for any help/suggestions.
Wei Jen Yeh yeh@cs.purdue.edu
Department of Computer Science
Purdue University
West Lafayette, Indiana
--
Wei Jen Yeh yeh@cs.purdue.edu
Department of Computer Science
Purdue University
West Lafayette, Indianatim@dell.co.uk (Tim Wright) (03/11/91)
In <13777@medusa.cs.purdue.edu> yeh@cs.purdue.EDU (Wei Jen Yeh) writes: ... > The next questions are for people running Dell 4.0 and have used any comm. >program under it. I use kermit to connect to the computer at school with a >2400 baud modem. When doing a long cat on the remote host, the local m/c >will split out about 20-30 lines of text with intermittent stops, then the >rest of the output is not displayed. The connection is still there. It looks >like the async input buffer was full and the input handler just ignored the >incoming characters without blocking the sender. Has anyone seen this problem? >BTW, this occured under both X and the ascii console. This sounds like flow control. If you're using C-Kermit, check your setup. 'set flow-control xon'. In fact it sounds more like your modem setup. C-Kermit defaults to xon-xoff flow control, but the modem setup could be wrong at either end. The only way to confirm is with a protocol analyzer. > Another question. A quit (ctrl-C) when executing some programs >causes ksh to dump core. A reproducible example is the command >"zcat gcc-1.39.tar | tar tvf -". ksh prints the messages after ctrl-C is >pressed: >ksh: 24235 Quit(coredump) >ksh: 24234 Quit(coredump) >, where the two integers are pid's. This is not ksh dumping core. You have said '^c' is mapped to QUIT, not INTR. That is it is sending SIGQUIT. You had a pipeline of two processes (24234, the zcat, and 24235, the tar), therefore it is quite natural for both to coredump. Ksh (the shell you invoked them from) is reporting the fact - see 'set -o monitor'. Regards, Tim -- Tim Wright, Dell Computer Corp., Bracknell | Domain: tim@dell.co.uk Berkshire, UK, RG12 1RW. Tel: +44-344-860456 | Uucp: ...!ukc!delluk!tim Nobody ever said I was charming before. They said, "Rimmer, you're a total git" - Red Dwarf, "Camille".
cpcahil@virtech.uucp (Conor P. Cahill) (03/11/91)
yeh@cs.purdue.EDU (Wei Jen Yeh) writes: > This is my situation. I'm running Dell's 4.0 on a 386-20. It has 8mb of >memory, and does not have cache or a 387. I usually work under X and have >three to four xterms opened. The system gets REALLY SLOW when a compilation >is taking place. It gets even worse when lisp is running. You can count the >characters when they are displayed on the screen! So, the question is, >how do I upgrade my system? A faster machine, more memory, or a math-co? NOTE: This response deals mostly in System V R3.2, not 4.0. However, the work should be verry similar, if not the same, under 4.0. Instead of asking the net for a "general" answer, why not see for yourself what the problems are. Run a couple of SAR reports while the system is running "REALLY SLOW" to see if you can determine why it is slow. The two main reports for you to look at are: 1. the standard report (system utilization report) % sar 5 5 virtech virtech 3.2 2 i386 03/11/91 06:44:04 %usr %sys %wio %idle 06:44:09 1 4 0 95 06:44:14 1 4 0 95 06:44:19 1 4 0 95 06:44:24 1 4 0 95 06:44:29 0 4 0 95 Average 1 4 0 95 This report shows that my system is pretty much idle. No need for more CPU power right now. (NOTE that even unless you are maintaining verry little idle cpu over long periods of time, your CPU is probably enough. In other words, don't get shocked if you see 0% idle when running this report) 2. The memory usage report % sar -r 5 5 virtech virtech 3.2 2 i386 03/11/91 06:48:34 freemem freeswp 06:48:39 1689 64048 06:48:44 1681 64048 06:48:49 1691 64048 06:48:54 1681 64048 06:48:59 1688 64048 Average 1686 64048 This shows the amount of free memory and free swap space. The tricky part about this report is that free memory is listed as the number of 4K pages that are free, while free swap is the number of 1K disp pages that are free (so I have just over 6MB of free memory and 32MB of free swap). This is the report that will probably show you that you are swapping which slows down the system trememdously. If you are swapping, get more memory. It is more then worth it. 3. The next report isn't out of SAR, but it will help you if you are tight on memory. After running you system for a while (and having gone through several of your REALLY SLOW episodes) run the following: % netstat -m alloc inuse total max fail streams: 512 69 689 76 0 queues: 2048 386 4010 428 0 mblocks: 4440 216 2527703 1158 0 dblocks: 3552 216 2189382 1032 0 dblock class: 0 ( 4) 512 0 59837 4 0 1 ( 16) 1024 28 275442 241 0 2 ( 64) 1024 19 1663352 679 0 3 ( 128) 512 161 79344 194 0 4 ( 256) 256 0 25611 4 0 5 ( 512) 128 8 53617 15 0 6 (1024) 32 0 30761 12 0 7 (2048) 32 0 1416 17 0 8 (4096) 32 0 2 1 0 This shows you how much STREAMS buffering you have configured. The key to this report is that you want to have no failures and if you are tight on memory you want to have your alloc collumn be as close to your max as you feel comfortable. I tend to like to keep alloc 20% above max, but I'm not tight on memory. If I was tight on memory I would change the kernel configuration parameters (in /etc/conf/cf.d/stune) as follows: NSTREAM 96 NQUEUE 432 NBLK4096 2 NBLK2048 18 .... (you get the idea) >I understand that 387 will improve the X performance (at leaset for Dell's >stock X11R4). (That brings up another question. Is Roell's port of X11R4 The 387 does not do much for xterms on X11R4. (The server has much of it's floating point operations removed and xterms don't need to do much in the way of floating point). If you are doing drawings or other such FPU intensive operations, I would recommend a 387, but it doesn't sound like you are. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170