rob@dhw68k.cts.com (Robert Kenyon) (03/11/88)
We have an overworked Sperry IT. It is running xenix and is used to make
software orders (disk and tape) and for development (approx 5 users). As
you can well imagine, we are starting to find problems with response time.
We are looking into speeding this little guy up. What does the world
suggest? Replace the board? Add an inboard 386? What's the story?
It currently runs 8Mhz, 4M ram, 245M hard disk, 18 serial ports (two
computone atx 8 ports). We are a Xenix house and a change of OS is
obviously out of the question (though and upgrade to Xenix 386 is not).
Any and all suggestions will be appreciated.
Possible fears:
Is system I/O bound? Do you think that we are using all 8MHz of
our buss? If so, would a 20MHz 386 actually help?
Memory? w/Inboard. What good is a 16Mh 386 that accesses memory at
8Mh? Should we throw out the 3.5 of ram?
HELP!!!
--
I once was here but now I'm not. And no one's gonna pin it on me...
Robert Kenyon - {trwrb,hplabs}!felix!dhw68k!rob - InterNet: rob@dhw68k.cts.comdavidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (03/15/88)
In article <5815@dhw68k.cts.com> rob@dhw68k.cts.com (Robert Kenyon) writes: >We have an overworked Sperry IT. It is running xenix and is used to make >software orders (disk and tape) and for development (approx 5 users). As >you can well imagine, we are starting to find problems with response time. There are a number of things you may be out of, here are a few thoughts. MEMORY: I think the easiest way to check this is to do a "ps -el" from time to time, and look at the flags field. If bit zero is off the process is swapped out. Swapping will steal bus bandwidth and io time. If you have inhouse software running in small model, make sure the "-i" switch is on, to allow sharing the text segment. Add more memory (obviously). This will also results in more disk buffers. I usually recommend 1.5 MB for the system and 512k per user. Make that 1 MB per user for software development. I think you're WAY under what you need. CPU: I could believe that you're running out of that, too, although I bet not as much as memory. Look at your CPU usage during a busy period, or at least one when the response is down. Look at the cululative CPU for idle, user, and sys, and save the numbers. Then look 10 minutes later. Anything less than 25% idle will usually mean bad response. BACKPLANE: I really don't know how to measure this, but looking at the speeds of the CPU and disk DMA channels, I can't see that it would be a problem. A smart serial board should avoid running you out of CPU for interrupts, but look at the ratio of kernel to user (and idle) time. Comments ======== If you don't have your own set of tools I'll mail you a copy of some programs I have to measure the things I mentioned (they were psoted a while ago to another group, I fixed 'em). I will post if requested, but can't and won't mail copies to more that two or three people. I also have a useful and accurate copy of acctcom, written from scratch, which tells you a lot of useful things the xenix acctcom doesn't. It even knows what the core size is ;^) I find that my 386 is about 2:1 fast than an AT (no surprise), and that recompiling a C program in 386 mode gets me another 2:1 (wow). In addition the paged memory reduces swap/moves, and thereby kernel time. In all I estimate that it is %x my 8MHz AT. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me