haugj@pigs.UUCP (Joe Bob Willie) (08/29/88)
In article <1988Aug26.235151.18037@gpu.utcs.toronto.edu> woods@gpu.utcs.Toronto.EDU (Greg Woods) writes: >How about running it for a couple of weeks, with no nice factor, along >with a shm and a sem tester, in multiple incarnations. Meanwhile, do >a WHOLE lot of disk and tty I/O. In other words, push it to the limit. >Make the machine so slow as to be un-usable for anything else. when the load average on my systems here at work get up over 15 or 20, we start counting the minutes until the machine crashes. if i was planning on running the mix you suggest, i would get a bigger machine. we manage to find all manner of race conditions in the kernel running that heavy of a load. go get some hardware that can handle the load without thrashing. better still, go read the source code and look at all those wonderful comments about where and what races exist. unix from anyone is far from 100% bug free. no fair dumping a load suitable for a vax 8850 on an intel 8088. any consultant or system builder or whatever who actually believes you can run 32 users on an AT/286 running xenix is brain-dead. i don't even know if i'd put 24 users on anything smaller than a 20MHz compaq. if you are stupid enough to overload a machine from a design perspective, and still expect it to work, you get what you deserve. ANY system if suitably overloaded will degrade. with races present, ANY suitably overloaded system will FAIL. last time i checked there were quite a few race conditions remaining in the at&t code. i am certain some were in the ipc code. but most of all, if all you can do is bash SCO. don't bother. we all know how much you hate xenix. -- =-=-=-=-=-=-=-The Beach Bum at The Big "D" Home for Wayward Hackers-=-=-=-=-=-= Very Long Address: John.F.Haugh@rpp386.dallas.tx.us Very Short Address: jfh@rpp386 "ANSI C: Just say no" -- Me
woods@gpu.utcs.toronto.edu (Greg Woods) (08/31/88)
In article <380@pigs.UUCP> haugj@pigs.UUCP (Joe Bob Willie) writes: >when the load average on my systems here at work get up over 15 or 20, >we start counting the minutes until the machine crashes. if i was planning >on running the mix you suggest, i would get a bigger machine. we >manage to find all manner of race conditions in the kernel running that >heavy of a load. go get some hardware that can handle the load without >thrashing. I agree. Unfortunately, you often can't tell a user (ie: client) that. They just won't believe you, (and if you think I hate Xenix :-( ...). Also, unfortunately, except for the interrupts from the "tons of I/O", which weren't there after we got smart I/O cards (from Consensys), the load I described doesn't really require that much CPU. In fact, the load average on a machine running as our "network" server was lower than when I ran simultaneous compiles. The compiler didn't seem to cause any crashes. The machine certianly wasn't thrashing, either when compiling, nor testing. [BTW: let's not argue about "load averages", and yes, they were seperate machines for testing and development.] >better still, go read the source code and look at all those wonderful >comments about where and what races exist. unix from anyone is far >from 100% bug free. no fair dumping a load suitable for a vax 8850 on >an intel 8088. I never said it was bug free. What I was trying to get across was the fact that the implementation of Xenix (in general) is considerably buggier than lots of other "versions" of Unix. I've had lots of reports of known and sometimes fixed bugs in the AT&T code. Even (especially) in the IPC stuff. However, let's not give the impression that Unix is a buggy, old, monster. It is probably better than many other "systems" of similar size and complexity. It certianly has enjoyed the time and usage to give it a great deal of maturity. One of the problems (and benifits) of a system supplied with optional source is that those with source can fix problems on the spot. The rest of us have to wait for AT&T, or our vendors, to discover the same problems, and make the same fixes, or hope that fixes filter their way back to AT&T and eventually are released to us. At the same time, I still believe that a lot of the extra bugs come from the compiler that SCO uses (ie: MS-C). They will be in a much better position now that they are beginning to use the latest version, and if it is as good as it is cracked up to be, Xenix may get considerably better "overnight". I also believe that a large number of bugs stem from the heritage of Xenix (ie: it's "still" basically an "enhanced" 7th Edition Unix). A lot of the so-called Xenix "features" are really just backwards compatibility for things that have, for the most part, disappeared "eons" ago! (Now we're talkin' MONSTER. Imagine if there was support for V7 tty, SysIII tty, BSD newtty, termio, AND streamio?) BTW: Those SCO guy's got a bad reputation (at least with the people I've talked to) when they delivered the 386 OS with utilities compiled by the 286 compiler. I think they did this because of a then VERY buggy 386 compiler. (it was either that, or the fact that they were so over-worked doing support, they didn't have time to re-compile everything :-). The latest version of 386/ix [1.0.6] includes a new compiler, and EVERYTHING has been re-compiled. In fact, it is rumored that the "upgrade" consists of an entire set of floppies. (The current version [1.0.5] runs quite well as is!) The question is: should I re-compile all my software too? :-) [ We agree on one thing: ANSI C may not be what it's cracked up to be :-). However, if you're using the Xenix compiler, you have do deal with a considerably more "ANSI'fied" compiler than I!] -- Greg Woods. UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada
fred@cdin-1.uucp (Fred Rump from work ) (09/02/88)
In article <1988Aug30.195807.11264@gpu.utcs.toronto.edu>, woods@gpu.utcs.toronto.edu (Greg Woods) writes: [ In article <380@pigs.UUCP[ haugj@pigs.UUCP (Joe Bob Willie) writes: [ >when the load average on my systems here at work get up over 15 or 20, [ >we start counting the minutes until the machine crashes. if i was planning [ [ I agree. Unfortunately, you often can't tell a user (ie: client) that. [ They just won't believe you, (and if you think I hate Xenix :-( ...). If I had a user whose system constantly crashed and he still won't listen to my advice, I would not feel sorry for him. I would also not spend a great deal of time trying to fix things that wouldn't have happened if they'd have listened to me in the first place. Sort of makes this whole discussion mute, doesn't it? [ I never said it was bug free. What I was trying to get across was the [ fact that the implementation of Xenix (in general) is considerably [ buggier than lots of other "versions" of Unix. What is it three, four months before the name Xenix will dissappear? SCO and Microsoft have officially been notified that with 3.2 they'll be allowed to use the UNIX word. They will for the 386 world. We can then bitch about UNIX bugs together. [ I've had lots of reports of known and sometimes fixed bugs in the AT&T [ code. Even (especially) in the IPC stuff. However, let's not give the [ impression that Unix is a buggy, old, monster. It is probably better [ than many other "systems" of similar size and complexity. See above. [ [ BTW: Those SCO guy's got a bad reputation (at least with the people [ I've talked to) when they delivered the 386 OS with utilities compiled [ by the 286 compiler. I don't know about reputation - but I do know about questioning stares. While there are bugs in the Xenix c compiler and in Xenix in general, they affect developers only. Most of these 'smart' users know how to get around these little buggers of life to produce a product they can sell that works, in an operating environment, that doesn't crash, that never loses data, and that doesn't cost an arm and a leg to support. I think that is the message here. -- Fred Rump, Pres. | UUCP: {rutgers,cbmvax,bellcore}!bpa!cdin-1!fred CompuData, Inc. | or ...{allegra killer gatech!uflorida decvax!ucf-cs} 10501 Drummond Rd. | !ki4pv!cdis-1!cdin-1!fred Philadelphia, Pa. 19154| or ...!bikini.cis.ufl.edu!ki4pv!cdis-1!cdin-1!fred