len@netsys.COM (Len Rose) (01/15/89)
I am evaluating V/AT 2.4 on an 8 mhz clone 286 with 1 meg
of ram. Can't reliably sustain a uucp transfer at speeds
greater than 2400 baud. The system is extremely slow ,and
is virtually unusable with a 16 bit compress running in the
background.
I despise Xenix yet it seems that SCO Xenix runs rings around
V/AT on the same hardware.
My question is: Is V/AT really this bad,and if so, how can they
still be in business? I am sure the hardware isn't the blame since
Xenix performs "acceptably" give the fact that it's just a 286.
Stunned and open to advice.
--
len@netsys.com
{ames,att,rutgers}!netsys!lenrolfe@w3vh.UU.NET (Rolfe Tessem) (01/15/89)
In article <11871@netsys.COM>, len@netsys.COM (Len Rose) writes: > I am evaluating V/AT 2.4 on an 8 mhz clone 286 with 1 meg > of ram. Can't reliably sustain a uucp transfer at speeds > greater than 2400 baud. The system is extremely slow ,and > is virtually unusable with a 16 bit compress running in the > background. > I have a Telebit Trailblazer, and regularly do 9600 baud UUCP sessions with V/AT 2.3 on a 10 Mhz clone. I do have 3 meg of RAM though, and I suspect that some of your performance problems stem from the fact that 1 meg is the absolute minimum the system will run with -- as you start adding memory, performance increases dramatically. Having said that though, I'll agree that 16 bit compress is a drag on the system, even with 3 meg installed. -- UUCP: uunet!w3vh!rolfe | Rolfe Tessem INTERNET: rolfe@w3vh.uu.net | P.O. Box 793 AMPRNET: rolfe@w3vh.ampr.org [44.44.0.1] | Great Barrington, MA 01230 PACKET RADIO: w3vh@wa2pvv | (413) 528-5966
john@wa3wbu.UUCP (John Gayman) (01/15/89)
In article <11871@netsys.COM>, len@netsys.COM (Len Rose) writes: > I am evaluating V/AT 2.4 on an 8 mhz clone 286 with 1 meg > of ram. Can't reliably sustain a uucp transfer at speeds > greater than 2400 baud. The system is extremely slow ,and > [stuff deleted] > My question is: Is V/AT really this bad,and if so, how can they > still be in business? I am sure the hardware isn't the blame since > Xenix performs "acceptably" give the fact that it's just a 286. > I can't emagine what the problem could be. I don't observe any of those characteristics here. My configuration is a CompuAdd 8 Mhz 1-wait state AT-clone, 8-port dumb Digiboard, Telebit Trailblaser Plus, Hayes SM-2400 and Microport 2.4U. (I'm using 3MB of Ram) I have no trouble sustaining two 2400 baud uucp's simultaneously and doing something else on the console. The only thing I notice is that when doing a 9600 baud News feed, obviously other serial activity will cause the modem to pause for a moment and then resume. I have also run a 9600 baud direct-wired uucp connection to my 386 machine and have no trouble. If I remember correctly when I first got V/AT, I also had only 1MB of Ram. Even running the small kernel the system was very slow and swapped to disk constantly. I think the single biggest performance boost you could simply acheive would be another 2MB of Ram. Overall, in the 2 years I've been running the V/AT system it has proved very stable (no crashes for months at a time) and met my needs. John -- John Gayman, WA3WBU | UUCP: uunet!wa3wbu!john 1869 Valley Rd. | ARPA: john@wa3wbu.uu.net Marysville, PA 17053 | Packet: WA3WBU @ AK3P
debra@alice.UUCP (Paul De Bra) (01/16/89)
In article <11871@netsys.COM> len@netsys.COM (Len Rose) writes: >I am evaluating V/AT 2.4 on an 8 mhz clone 286 with 1 meg >of ram. Can't reliably sustain a uucp transfer at speeds >greater than 2400 baud. The system is extremely slow ,and >is virtually unusable with a 16 bit compress running in the >background. > >I despise Xenix yet it seems that SCO Xenix runs rings around >V/AT on the same hardware. > >My question is: Is V/AT really this bad,and if so, how can they >still be in business? I am sure the hardware isn't the blame since >Xenix performs "acceptably" give the fact that it's just a 286. > There are several aspects about V/AT that make it slow. I have tested an earlier version and my conclusion at that time was the same as yours: How can they still be in business selling this software that is virtually unusable. There are however a few explanations: 1) The kernel is a large model program, compared to a middle model program in SCO Xenix. This has 2 implications: - it is slower, because accessing data is slower in the large model. however, it's not really that bad. - it is BIGGER. With only 1 meg V/AT is incredibly slow because there is not much room left for processes. However, with more memory having the large model kernel has the advantage that you can make system tables larger to increase the overall performance, and increase system limits on open files, processes, I/O buffers, etc. 2) Most newer 286 machines run at 10Mhz without wait states or faster (12, 16 or even 20Mhz). As the number of cpu-cycles per second for the "household" of the kernel is more or less fixed (a fixed number of clock interrupts per second) the kernel takes up a larger fraction of the available cpu-time on a slower machine. 3) V/AT used to have incredibly slow disk access and throughput (compared to Xenix on the same machine). This may be hardly noticeable when you are working single user and do not have anything in background, but in your case with a compress in background, that is a) using lots of cpu- cycles, b) doing disk I/O and c) being swapped in and out as your system does not have enough memory, the system ends up "thrashing". I do believe V/AT can be quite comfortable on faster 286 machines with at least 2 meg. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
len@netsys.COM (Len Rose) (01/16/89)
While I generally would have to agree that memory is at the
heart of my problems with V/AT,it speaks volumes of the actual
quality of their port. I have run Unix on some pretty lame
hardware configurations on many different systems and none
performed this badly. Plus, there is serious trouble with the
serial drivers.. I am sure this has been thrashed to death here
previously so I won't add anything else. Too bad that SCO Xenix
has proven itself superior in all respects. I am decidely in
the System V camp , and refuse to use anything else on the
mini's we have here.
I was tasked to find a usable "Unix" for several office systems
currently running DOS and one that wouldn't require massive
investment hardware-wise for aging hardware that will be outmoded
soon.. It looks like SCO Xenix is the winner.
Thank God I don't have to use these systems on a daily basis.
Anybody want to buy a used AT :-)
--
len@netsys.com
{ames,att,rutgers}!netsys!lendebra@alice.UUCP (Paul De Bra) (01/16/89)
In article <11899@netsys.COM> len@netsys.COM (Len Rose) writes: >... >I was tasked to find a usable "Unix" for several office systems >currently running DOS and one that wouldn't require massive >investment hardware-wise for aging hardware that will be outmoded >soon.. It looks like SCO Xenix is the winner. > >Thank God I don't have to use these systems on a daily basis. > >Anybody want to buy a used AT :-) > What a world are we living in... I agree one can get pretty upset when a system performs as poorly as you described in an earlier posting. However, an AT (8Mhz will do) gives you about 0.5MIPS (though it varies depending on what you try) In a poor University where the "BIG" Unix system was a Gould mini, roughly performing like a Vax 785, i.e. 1.5MIPS, I was *very* happy to get an AT. Since on average about 16 people were doing either software development or heavy text processing (with Tex) on the mini, the AT was a much more comfortable working environment, delivering a stable performance. I never thought people would think badly about Xenix because some commands are different from plain vanilla System V. My Xenix box was always a bit different from the mini, but that never bothered me. It was Unix, and the names of the commands and the available options are described in the manuals. Who would want more? (too bad my system blew up...) Just a few years ago the idea of having a 750 (well, more or less) on your desk for under $2000 was fabulous. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
tkevans@fallst.UUCP (Tim Evans) (01/17/89)
In article <11899@netsys.COM>, len@netsys.COM (Len Rose) writes: > > While I generally would have to agree that memory is at the > heart of my problems with V/AT,it speaks volumes of the actual > quality of their port. I have run Unix on some pretty lame > hardware configurations on many different systems and none > performed this badly. Plus, there is serious trouble with the > serial drivers.. I am sure this has been thrashed to death here > previously so I won't add anything else. Too bad that SCO Xenix > has proven itself superior in all respects. I am decidely in > the System V camp , and refuse to use anything else on the > mini's we have here. > I'm a uPort user, too (2.4), but it appears that this and other similar messages have got it right. You simply _must_ have large amounts of RAM to run uPort succesfully on an AT. For those who are considering 286 *NIX implementations for general office-type work (*N*O*T* for software development, though), take a look at VenturCom's Venix. At the Social Security Administration, we run standard old 6-mhz AT's, with 1 meg RAM, for office automation purposes and they serve 2 users real well for most purposes. Venix 286 has serious problems when it comes to software development (even though the package is fully bundled, with software development and text-processing packages), and, at 1 meg, heavy use of our spreadsheet (Tactician) with large spreadsheets tends to drag them down real quickly. Nevertheless, for general word-processing and other standard office tasks, Venix works real well. Now, getting support from VenturCom or its VAR's, and software applications that run on it is another question. VenturCom is a very small company and ports to it are far and few between. -- UUCP: ...!{rutgers|ames|uunet}!mimsy!aplcen!wb3ffv!fallst!tkevans INTERNET: tkevans%fallst@wb3ffv.ampr.org OTHER: ...!attmail!fallst!tkevans Tim Evans 2201 Brookhaven Court, Fallston, MD 21047 (301) 965-3286
det@hawkmoon.MN.ORG (Derek E. Terveer) (01/18/89)
In article <391@w3vh.UU.NET>, rolfe@w3vh.UU.NET (Rolfe Tessem) writes: > In article <11871@netsys.COM>, len@netsys.COM (Len Rose) writes: > > I am evaluating V/AT 2.4 on an 8 mhz clone 286 with 1 meg > > of ram. [..] The system is extremely slow [..] > > [..] I suspect that some of your performance > problems stem from the fact that 1 meg is the absolute > minimum the system will run with -- as you start adding > memory, performance increases dramatically. I agree. I was running (at work, believe it or not!) a xenix system with 512K of memory, and boy was that slow!!!! Combine the small, no; make that "miniscule", amount of memory with the file advisory/mandatory locking problems in that release of xenix (2.1.3, ugh!), and i had processes that would take in excess of a week to run instead of 5 minutes. I would almost venture to say, in an off the cuff manner, that you get exponential performance improvements in all of the various flavours of unix as you progress from the basement (0.5M) to something like 2 or 3Meg. The performance improvements are still there beyond that, they just aren't as noticable. (Of course, i don't have the money to spend on memory, so i can't *really* say how noticeable these improvements are beyond a "workable" system, i.e., one that has approximately 2.5-3.5M of memory. Perhaps someone else can chat on the 4M+ range.. (:-)) Trying to evaluate your 286 unix system with 1M is not really a fair test of its potential, much like (for you airplane types) putting a lawnmower engine in a P47-Thunderbolt would not really show off the power of that plane...! (:-) (Sorry, i just *had* to say that) derek -- Derek Terveer det@hawkmoon.MN.ORG || ..!uunet!rosevax!elric!hawkmoon!det w(612)681-6986 h(612)688-0667 "A proper king is crowned" -- Thomas B. Costain
rcd@ico.ISC.COM (Dick Dunn) (01/19/89)
In article <11871@netsys.COM>, len@netsys.COM (Len Rose) writes: > I am evaluating V/AT 2.4 on an 8 mhz clone 286 with 1 meg > of ram. Can't reliably sustain a uucp transfer at speeds > greater than 2400 baud... >...I despise Xenix yet it seems that SCO Xenix runs rings around > V/AT on the same hardware. We did some measurements and some tests on Xenix serial I/O a fair while ago. We found that it was fast at the async stuff but there were other problems--like the clock losing a lot of time. It looked as if they were playing some tricks with keeping interrupts off or juggling priorities to put serial I/O highest. I don't recall the details (nor do I know if it's still that way) but it was clear that there was some "fudging" going on. > My question is: Is V/AT really this bad,and if so, how can they > still be in business? I am sure the hardware isn't the blame since > Xenix performs "acceptably" give the fact that it's just a 286. Don't be so sure the hardware isn't to blame! If you're actually taking an interrupt per character, you have a horrendous amount of overhead. The interrupt has to stack a bunch of stuff, and since the processor doesn't have any useful interrupt handling in itself, you have to go fiddle with the interrupt controllers (8259's) which are agonizingly slow and none too bright. If you miss the juggling on reprogramming the 8259 vs interrupt enable, you can set yourself up to get a second serial interrupt before you get out of the first one--so you overflow the kernel stack and die horribly. There's a 286 processor bug that causes a one-instruction window where interrupts aren't really disabled; this takes another dozen instructions to sort out and clean up. This is all before you ever get around to doing anything with the incoming character. I suspect it's possible to make things a lot faster by treating serial I/O as a very special case in interrupt handling, queuing characters and processing them in bunches, etc. I don't know how much of this Xenix does, but I have fought the battle of trying to make AT async I/O fast, and it really is hampered by the hardware. What can you do about it? For one, get some good serial hardware. The idea of having one character of buffering (or you might call it none at all--it's only the holding register) as the standard serial ports do is just plain dain bramaged. You need to be able to hold off the serial I/O to handle other interrupts (disk, clock) without dropping characters. The serial driver is presumably smart enough to check for more input having arrived before it leaves the interrupt routine--this will save the complete interrupt latency. (As you crank up the serial speed, you see the time in the kernel go up in proportion, then drop suddenly--because it starts getting two characters in on every interrupt cycle.) -- Dick Dunn UUCP: {ncar,nbires}!ico!rcd (303)449-2870 ...A friend of the devil is a friend of mine.
debra@alice.UUCP (Paul De Bra) (01/19/89)
In article <13736@ico.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes: >In article <11871@netsys.COM>, len@netsys.COM (Len Rose) writes: >> I am evaluating V/AT 2.4 on an 8 mhz clone 286 with 1 meg >> of ram. Can't reliably sustain a uucp transfer at speeds >> greater than 2400 baud... >>...I despise Xenix yet it seems that SCO Xenix runs rings around >> V/AT on the same hardware. > >We did some measurements and some tests on Xenix serial I/O a fair while >ago. We found that it was fast at the async stuff but there were other >problems--like the clock losing a lot of time. It looked as if they were >playing some tricks with keeping interrupts off or juggling priorities to >put serial I/O highest. I don't recall the details (nor do I know if it's >still that way) but it was clear that there was some "fudging" going on. > Sure, there is nothing magic in Xenix that makes the AT run faster than physically possible. In /usr/sys/conf/master you find a list of all device drivers and their priorities. The standard rule is to have the serial ports highest, and then the clock. Reason is simple: a lost interrupt from a serial port means that you lose an event external to your computer, i.e. an input character. You want to avoid that at all cost. The same is almost true for the clock, but one generally cares less about a lost clock tick. (I've never had my system lose time, but i've seen that happen to other systems.) All other events are more or less recoverable. A lost interrupt from the disk is a bit annoying because you have to time out and ask for the same info again but nothing is permanently lost. The parallel port idem. Interrupt driven drivers, combined with polling for timeouts goes a long way. The keyboard is very slow, so interrupts won't be lost easily on that device. I've played with these priorities, and there isn't too much you can do wrong that will slow down the system dramatically or crash it. The only effect you can get is that if the serial ports do not get the highest priority they start losing characters, which should be no surprise. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
debra@alice.UUCP (Paul De Bra) (01/20/89)
In article <773@hawkmoon.MN.ORG> det@hawkmoon.MN.ORG (Derek E. Terveer) writes: }In article <391@w3vh.UU.NET>, rolfe@w3vh.UU.NET (Rolfe Tessem) writes: }> [..] I suspect that some of your performance }> problems stem from the fact that 1 meg is the absolute }> minimum the system will run with -- as you start adding }> memory, performance increases dramatically. } }I agree. I was running (at work, believe it or not!) a xenix system with 512K }of memory, and boy was that slow!!!! Combine the small, no; make that }"miniscule", amount of memory with the file advisory/mandatory locking problems }in that release of xenix (2.1.3, ugh!), and i had processes that would take in }excess of a week to run instead of 5 minutes. } }I would almost venture to say, in an off the cuff manner, that you get }exponential performance improvements in all of the various flavours of unix as }you progress from the basement (0.5M) to something like 2 or 3Meg. The }performance improvements are still there beyond that, they just aren't as }noticable. (Of course, i don't have the money to spend on memory, so i can't }*really* say how noticeable these improvements are beyond a "workable" system, }i.e., one that has approximately 2.5-3.5M of memory. Perhaps someone else can }chat on the 4M+ range.. (:-)) } Something is missing in the above reasoning. Adding memory does not give your cpu more MIPS! A Xenix or Unix box with very little memory suffers in 2 ways: 1) there is not enough memory to have a reasonably sized I/O buffer pool, so most of the file I/O involves real disk I/O. 2) there is not enough memory to hold all processes so there is a lot of swapping. By adding memory these 2 problems go away. With System V/AT the buffer pool can grow very large, so file I/O keeps improving, mostly because disk I/O is very slow in V/AT, so you better have a large cache. With Xenix the buffer pool tops at about 1Mbyte (because of system-tables being limited to 64K). But above 512K the additional gain is really minimal, since disk I/O is fairly fast. Also, adding memory means that once you reach some amount of memory all your processes will fit in memory, so there will be no more swapping. Once you reached a state where you have a large buffer pool and no swapping any additional memory you add is a waste and will not contribute to performance in any way in a Xenix system (it may still do something in V/AT due to problems with the brk and sbrk implementation). Having a need for about 3 Mbytes on my system, and having bought 5Mbytes + 640K when memory was *very* cheap, I use 2Mbytes as a ram-disk, which was the only way to further improve performance. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
nvk@ddsw1.MCS.COM (Norman Kohn) (01/22/89)
In article <13736@ico.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes: >In article <11871@netsys.COM>, len@netsys.COM (Len Rose) writes: >> I am evaluating V/AT 2.4 on an 8 mhz clone 286 with 1 meg >> of ram. Can't reliably sustain a uucp transfer at speeds >> greater than 2400 baud... >What can you do about it? For one, get some good serial hardware... A strong second to that. I've been happy with Digiboard's intelligent multiport serial cards, but have had some kernel crashes when using modem control and I'm not sure that the latter has been fully ironed out yet. Also, DGB doesn't yet support shell layering for their intelligent controller. If modem control and/or shell layering are important to you (neither is relevant if you use card only for call-out) then look into Arnet or (gasp!) Bell. Beware that much of the complaints about the latter's support and responsiveness are true... yet the hardware products are solid and the associated drivers (though possibly not supported, at least for uport unix) are also good. The support problem is that Bell, now that it fancies itself a unix house as well, won't promise support or compatibility for future uport releases. -- Norman Kohn (...ddsw1!nvk!norman) eves: 373-0564 days/ans svc: 650-6840
det@hawkmoon.MN.ORG (Derek E. Terveer) (01/23/89)
In article <8804@alice.UUCP>, debra@alice.UUCP (Paul De Bra) writes: > Something is missing in the above reasoning. Adding memory does not give > your cpu more MIPS! I didn't mean to imply a performance improvement through gained mips. > A Xenix or Unix box with very little memory suffers in 2 ways: > 1) there is not enough memory to have a reasonably sized I/O buffer pool, > so most of the file I/O involves real disk I/O. > 2) there is not enough memory to hold all processes so there is a lot of > swapping. Yes, i estimate that my xenix system, with its 512K, was doing an incredible amount of swapping most of the time. In fact it seemed that the disk activity led was on about 20 to 22 hours a day. Concerning your other points about larger amounts of memory, i suppose that the amount of memory that is the point of no performance gain would depend on how active your system was and how many processes are required (want (:-)) to be in memory. Wouldn't you agree that a system with 3 active users on it would still show some improvement beyond, say 4M, than a system with just one user on it? derek -- Derek Terveer det@hawkmoon.MN.ORG || ..!uunet!rosevax!elric!hawkmoon!det w(612)681-6986 h(612)688-0667 "A proper king is crowned" -- Thomas B. Costain