jbr0871@fedeva.UUCP (Blaine Robertson) (01/05/88)
Our group will soon need to purchase one of these two products. We have
no experience in either of these items. Any recommendations or comments
would be appreciated.
Thanks,
Blaine Robertson
Federal Express
Memphis, TN
{hplabs!csun,gatech!emcard}!fedeva!jbr0871davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (01/06/88)
In article <252@fedeva.UUCP> jbr0871@fedeva.UUCP (Blaine Robertson) writes: | Our group will soon need to purchase one of these two products. We have | no experience in either of these items. Any recommendations or comments | would be appreciated. I have used both of these products for at least a year. I just bought Xenix/386 for my home system (with my own money, yet) and paid about the same for the runtime as I would for the entire MicroPort. MicroPort is ideal for the hobbiest who wants to have an inexpensive UNIX system. I'm told by MP that the latest version, 2.3, supports use of the serial ports at speeds greater than 1200bps. The C compiler seems better, too. Xenix is a more mature product, and seems much more reliable (in the use I see here and at home). I have been running Xenix for about 2 years now, and have *never* had a crash due to software. I run two serial lines, ethernet, and 100+ MB of disk, so it's not because I don't use the system. Xenix allows me to compile programs for DOS, or for smaller machines running Xenix/XT. This has saved me a lot of time in the past, but it may not be of value to you. MP C compiles COFF object modules, and is compatible with the versions offered by INterActive Systems. I have never worried about compatibility other than source. You will have to decide which is more cost effective for you. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
learn@igloo.UUCP (william vajk) (01/07/88)
In article <252@fedeva.UUCP>, jbr0871@fedeva.UUCP (Blaine Robertson) writes: > Our group will soon need to purchase one of these two products. We have > no experience in either of these items. Any recommendations or comments > would be appreciated. > At the moment, there is no question that uport does not work correctly. There is a promise of a newly fixed kernel ( post rev 2.3 ). The promise will have to be proven. If you need a product immediately, go to xenix. If you can hold off a bit, maybe *this time* uport has fixed it. I sure hope so.... Bill Vajk learn@igloo
jjw@igloo.UUCP (John Welch) (01/07/88)
In article <252@fedeva.UUCP> jbr0871@fedeva.UUCP (Blaine Robertson) writes: >Our group will soon need to purchase one of these two products. We have >no experience in either of these items. Any recommendations or comments >would be appreciated. There has been a lot of discussion (and flames) in comp.unix.xenix about this. To summarize our local experience, Microport is cheaper. It also has serious serial-port and hard-disk driver problems, and at least 4 times per week gives a double-panic. XENIX is reputed to behave much better. I have no experience to back up that claim. XENIX will cost about $250 more (discount mailorder) than Microport. -- ========================================================================== John Welch ..{codas,ihnp4}!ddsw1!igloo!jjw "I will not be pushed, filed, stamped, indexed, briefed, de-briefed or numbered. My life is my own; I am a free man!" - #6
mxb@pyuxf.UUCP (Michael Brochstein) (01/07/88)
In article <252@fedeva.UUCP>, jbr0871@fedeva.UUCP writes: > Our group will soon need to purchase one of these two products. We have > no experience in either of these items. Any recommendations or comments... While both products offer both advantages and disadvantages, for a business that needs a reliable and mature product, Xenix beats Microport hands down. Read the comparative reviews in both UNIX/WORLD and Unique (I don't remember which issues). I have Xenix running for about 17 months now and have had NO problems. -- Michael Brochstein Currently at Bellcore/PY4-B222 (201) 699-7177-work Piscataway, NJ DISCLAIMER: Bellcore doesn't consult me in most matters.
Usenet_area_"Cs.I.Pc"@watmath.waterloo.edu (01/08/88)
From Usenet: gargoyle!ddsw1!igloo!learn From: learn@igloo.UUCP (william vajk) Newsgroups: comp.sys.ibm.pc Subject: Re: XENIX VS Micoport Summary: right now.... Keywords: Which to buy?? Message-ID: <352@igloo.UUCP> Date: 6 Jan 88 20:48:32 GMT References: <252@fedeva.UUCP> Organization: igloo, Northbrook, IL Lines: 17 In article <252@fedeva.UUCP>, jbr0871@fedeva.UUCP (Blaine Robertson) writes: > Our group will soon need to purchase one of these two products. We have > no experience in either of these items. Any recommendations or comments > would be appreciated. > At the moment, there is no question that uport does not work correctly. There is a promise of a newly fixed kernel ( post rev 2.3 ). The promise will have to be proven. If you need a product immediately, go to xenix. If you can hold off a bit, maybe *this time* uport has fixed it. I sure hope so.... Bill Vajk learn@igloo --- via UGate v1.6 * Origin: watmath (221/163)
bhj@bhjat.UUCP (Burt Janz) (01/13/88)
In article <16217@watmath.waterloo.edu>, 221.162.fido!Usenet_area_"Cs.I.Pc"@watmath.waterloo.edu writes: > > Our group will soon need to purchase one of these two products. We have > > no experience in either of these items. Any recommendations or comments > > would be appreciated. > > > > At the moment, there is no question that uport does not work correctly. > There is a promise of a newly fixed kernel ( post rev 2.3 ). The promise > will have to be proven. If you need a product immediately, go to xenix. > > If you can hold off a bit, maybe *this time* uport has fixed it. I sure > hope so.... > Bill Vajk learn@igloo Oh, for crying out loud! I have Microport SV/AT 2.3, and am pleased as all heck about the state of the software. I've been using uport since 1.36, and have noticed nothing BUT improvements in each update of the software. I'm using a clone AT (no name - bought from the importer...), a Maxtor 1065 and a Quantum 540 (55 and 35mb), 2 serial/2 parallel, 3.5mb, and so forth... I have BOTH a DOS and UNIX partition on my boot disk, and can boot into either one from the prompt after the memory check. I have DOS/Merge and run 123 and Wordstar (ah, well... it works) under it. What do you want for ~$600? Perfection?!? And, with the number of problems that I note in comp.unix.xenix, XENIX hacks have NO room to flame on Microport! I obviously have news running, am currently porting a spreadsheet over to UNIX, doing other support work, have someone else dialing into my system and getting news, and do multiple other tasks under it. Recently I had a problem with my EGA. I got a new motherboard, and re-loaded the entire distribution. For some reason, I kept getting screwy terminal rewrites. First it was 25 line, then 23 line, then no scrolling. I called their support line. Within 1 minute (I ALWAYS time it!) I was talking to Doug Moran. I described the problem, and he told me that I needed to patch the Terminfo "ansi" description. He read me the patch over the phone. I got home, patched "ansi" as he said, and the system worked perfectly. The phone call was free - they have an 800 line during the day. Ok. So, we have a reasonably good product at a reasonably good price, with (at least) reasonably good support. That rates at least an A in my book. I've waited for a LONG time to get through to Microport to ask XENIX questions, and, more often than not, they DON'T have the answers right there at hand! So, QUIT FLAMING ON MICROPORT!!!!! YOU should do so well!!! Burt Janz ..decvax!bhjat!bhj
howardl@wb3ffv.UUCP (Howard Leadmon ) (01/15/88)
In article <353@igloo.UUCP>, jjw@igloo.UUCP (John Welch) writes: > > There has been a lot of discussion (and flames) in comp.unix.xenix about > this. To summarize our local experience, Microport is cheaper. It also has > serious serial-port and hard-disk driver problems, and at least 4 times per > week gives a double-panic. > XENIX is reputed to behave much better. I have no experience to back up that > claim. > -- I wonder why everyone has been having all this trouble with Microport UNIX, I have been running Microport System V/AT since the 1.3.6 release which was about two years ago. I have also had this version (now at 2.2U) running on several different machines, still no problems like mentioned above... I am now running Microport V/386 (System V Release 3) on my 80386 machines and haven't had any real problems with the thing yet. Now I have only had the 386 port up for about two months, but so far, so good. I am running the 80386 version on a WYSE-3216 machine (16mhz 80386) with 2meg SCRAM, 190 meg PRIAM Harddrive, and a Bell Technoliges ICC (smart serial controller) 6 port card. To date my biggest problem is getting debuged software for the ICC controller, but that is NO major problem. Oh, just one more tid-bit of information, I am also using the NEW Western Digital track cache harddrive controller at a 1:1 interleave (WD1006-WAH), and it has really helped the HD throughput. The 1:1 controller benchmarks with a 280% increase in HD performance. I just figured I would tell you how things are working out over on my end... Sincearly, Howard Leadmon cp1!sarin!wb3ffv!howardl (301)-335-2206
jjw@igloo.UUCP (John Welch) (01/20/88)
In article <166@bhjat.UUCP> bhj@bhjat.UUCP (Burt Janz) writes: >> If you can hold off a bit, maybe *this time* uport has fixed it. I sure >> hope so.... >> Bill Vajk learn@igloo > >Oh, for crying out loud! I have Microport SV/AT 2.3, and am pleased as all >heck about the state of the software. I've been using uport since 1.36, and >have noticed nothing BUT improvements in each update of the software. > >I'm using a clone AT (no name - bought from the importer...), a Maxtor 1065 >and a Quantum 540 (55 and 35mb), 2 serial/2 parallel, 3.5mb, and so forth... Igloo, too, has 2 serial ports, a no-name AT clone board and some monster disk drives. It, too, has news running, but ONLY when Bill shuts down EVERY user to do the poll. He's running at 2400 baud now, and going to 9600 shortly. Microport will NOT EVER keep up with this speed. Last weekend, I managed to get a 20Mhz '386 system on loan, just to see if the problems were Igloo's or Microport's. While UUCPing some mail between igloo and ddsw1, at the console I catted a large file. BOOM! went the poll. The problems get much worse if you use the 'unflicker' command to turn off console snow. It would appear that Microport does a CLI and WAITS, twiddling its thumbs with interrupts turned off, untill the vertical retrace happens. This is a VERY dumb thing to do. For $600, I expect something that WORKS. If you have $600 to throw away, kind si Burt, please throw it over to igloo so we can buy XENIX and get a system that WORKS for a change. -- ========================================================================== John Welch ..{codas,ihnp4}!ddsw1!igloo!jjw "I will not be pushed, filed, stamped, indexed, briefed, de-briefed or numbered. My life is my own; I am a free man!" - #6
learn@igloo.UUCP (william vajk) (01/20/88)
In article <166@bhjat.UUCP>, bhj@bhjat.UUCP (Burt Janz) writes: > Oh, for crying out loud! I have Microport SV/AT 2.3, and am pleased as all > heck about the state of the software. I've been using uport since 1.36, and > have noticed nothing BUT improvements in each update of the software. I too have noticed many improvements, and most were sorely needed by an immature product, rapidly approaching usability comparable to other OS software available, albeit at a somewhat higher price. I have not seen any 'enhancements' in the upgrades, or rather, if they are indeed there, from my vantage point, they have been overshadowed by the problems that still exist, the places where MY attention is focused. > I'm using a clone AT (no name - bought from the importer...), a Maxtor 1065 > and a Quantum 540 (55 and 35mb), 2 serial/2 parallel, 3.5mb, and so forth... For heaven's sakes, if you have a really working system, I DO want to hear about it, and want to hear exact details of the equipment you are running. I have heard fleeting commentary about 'microport works' and wish mine did. Please mail me your exact configuration, including whose sio board you are using, all the details. I might just be able to duplicate your success. Also please advise how many of the ports are actively used, and how many are used at one time. Is your system public access ? Do you get the newsfeed at a time that you and/or others are accessing the system ? Or is your newsfeed at a time when nothing else is happpening ? It is very easy to say 'it works' and just as easy for me to say 'mine doesn't.' Point is, there are apparently conditions where it does, and times/circumstances where it won't. I've been working as much as possible with uport to close that gap, and will continue to do so. The new drivers are installed on igloo, and that has given some relief. > What do you want for ~$600? Perfection?!? And, with the number of problems > that I note in comp.unix.xenix, XENIX hacks have NO room to flame on > Microport! First of all, the microport I purchased was well over $700 (1.36), and I purchased one upgrade (2.3) for it, so the total is approximately $800. I am not a XENIX hack, barely a UNIX hack, and I've devoted an inordinate amount of time to uport on this system. Money has nothing to do with this, though if it did, the complete xenix package can be found for just under $1000 thru discounters ('286 version). If a bus that you paid 50 cents to ride runs late, and you have resulting problems, is it ok cause 'what can you expect for 50 cents ?' Gimme a break already, and quit with the religion here. People buy a product expecting it to work, and don't buy a cheaper product (softwarewise) as a compromise to needed functionality. > I obviously have news running, am currently porting a spreadsheet over > to UNIX, doing other support work, have someone else dialing into my system > and getting news, and do multiple other tasks under it. Wasn't obvious to me. Does this 'other person' (I assume you mean one person or machine) run 'rn' while you are getting your newsfeed ? I have no problems when the console is being used for limited tasking now either, and cpu loading is never a problem. Offsite users running bbs software, or even catting a file using a pager, do cause sufficient timeouts to lose the feed, at least they do on igloo. I want to hear some success stories under these circumstances. I can run two polls to other machines at the same time. Screen refresh is what seems to kill off polling. > Ok. So, we have a reasonably good product at a reasonably good price, with > (at least) reasonably good support. > When you call to get a patch for a manufacturer's problem, that isn't support, that's repair. When you call cause you don't know something, or botch it up yourself, that's support. I have asked for repairs and so, obviously, have you in the case of the ansi terminfo. It was broken, they repaired it, and that bodes well of any vendor. I hope the rest of the repairs are as rapidly forthcoming. If I didn't have faith in uport fixing problems in the very near future, I wouldn't bother working with their product, and would already have switched to xenix. As things presently stand, I am working in concert with engineering at uport, have offered my machine as a place to let pedestrian users beat the heck out of the product, and report how well/badly stuff works here under a field level stress on a machine with an etc/passwd file that is 137 lines. Maybe not big by conventional standards, but sizable for a little '286 box with 2 phone lines, the full development package, the documenters' workbench package, a full newsfeed, and two commercial BBS packages running side by side, sporting 92 megs worth of HD and 5.5 meg ram. Please follow up with mail regarding your exact hardware configuration. Thanks. Bill Vajk learn@igloo
jjw@igloo.UUCP (John Welch) (01/30/88)
In article <428@cimcor.UUCP> mike@cimcor.UUCP (Michael Grenier) writes: >> >> Igloo, too, has 2 serial ports, a no-name AT clone board and some >> monster disk drives. It, too, has news running, but ONLY when Bill shuts >> down EVERY user to do the poll. He's running at 2400 baud now, and going to > > >Strange, my Microport system with the same configuration seems to work >great. Perhaps, your no name clone does have problems. > > -Mike > {ihnp4, amdahl, rutgers}!meccts!cimcor!mike Very strange, because when using Microport with several different motherboards, the same problem exists. Also, when using Tandy XENIX on the same motherboards, the problem goes away. Are you running anything while getting a LARGE (more than 3 meg compressed) of news? Try catting a large text file from the main console at that time, and wave bye-bye to Microport. By the way, the problem got better (did NOT go away) when we installed a 20Mhz '386 board with 4 Meg of .6 wait-state RAM. The problem has also gotten better when a faster (40ms as opposed to 65ms) drive has been used for news storage. It seems to me that Microport needs to do some work on the device drivers to get them running correctly on an AT. -- ========================================================================== John Welch ..{codas,ihnp4}!ddsw1!igloo!jjw "I will not be pushed, filed, stamped, indexed, briefed, de-briefed or numbered. My life is my own; I am a free man!" - #6
learn@igloo.UUCP (william vajk) (01/30/88)
In article <428@cimcor.UUCP>, mike@cimcor.UUCP (Michael Grenier) writes: > > > > Igloo, too, has 2 serial ports, a no-name AT clone board and some > > monster disk drives. It, too, has news running, but ONLY when Bill shuts > > down EVERY user to do the poll. He's running at 2400 baud now, and going to > > > Strange, my Microport system with the same configuration seems to work > great. Perhaps, your no name clone does have problems. Your statement might bear some validity, but we emplaced a name brand known good and working 20 MHz '386 motherboard in the box for a weekend, complete with 4 megs of simm ram, and experienced the same problems. We have swapped about several well known sio cards, including a dumb 8 digiboard (presently on loan to another system and running fine under xenix.) The only parts of this system that have not been test exchanged are the CGA card, the HD controller card, and the fast HD's themselves( a 40 meg seagate, and a 72 meg miniscribe.) These too will be swapped for testing, but all indications are that the problems lie with the software. I have witnessed the same problems igloo sees on stock Televideo and Tetung machines. Maybe they were hardware problems too. Strange that xenix runs just fine on them. Igloo now sports a trailblazer, running polls at 9600. The new sio driver here for beta test from uport works nicely. Bill Vajk learn@igloo
mike@cimcor.UUCP (Michael Grenier) (02/01/88)
In article <377@igloo.UUCP>, jjw@igloo.UUCP (John Welch) writes: > Very strange, because when using Microport with several different motherboards, > the same problem exists. Also, when using Tandy XENIX on the same motherboards, > the problem goes away. Are you running anything while getting a LARGE (more > than 3 meg compressed) of news? Try catting a large text file from the main > console at that time, and wave bye-bye to Microport. I'm sorry, I don't get that much news at a shot to run your test though I'd be suprised if it did anything to the system. I've also set the Nice value in defs.h(?) in the news software to run the uncompression at a lower priority. I have catted (sp?) large text files without any problem while news was unpacking, at the same time as my wife was working on the 9600 baud vt200 terminal. You mentioned an improvement going from the 65ms drives to the 40ms drives. Perhaps the reason for my success is my faster 28ms drives (maxtor 1140). I've had this system running since I installed version 2.3 with dosMerge for a couple months now without any crash at all. Maybe Microport isn't robust for all hardware configurations but it sures works good on this one. -Mike {rutgers, amdahl, ihnp4}!bungia!cimcor!mike
manes@dasys1.UUCP (Steve Manes) (02/02/88)
In article <428@cimcor.UUCP> mike@cimcor.UUCP (Michael Grenier) writes: >> Igloo, too, has 2 serial ports, a no-name AT clone board and some >> monster disk drives. It, too, has news running, but ONLY when Bill shuts >> down EVERY user to do the poll. He's running at 2400 baud now, and going to > > >Strange, my Microport system with the same configuration seems to work >great. Perhaps, your no name clone does have problems. I doubt it. I had the same problem with disk/tty interrupts overflowing and crashing Microport. The last time it happened, 'fsck' also destroyed my root file system on reboot. This crash occurred with two 1200 baud users on-line and a 'doscp' to a floppy. My Microport machine was a Smartek with a Seagate 4096. The next week my main UUCP feed, also running Microport V/AT on an AST machine with a 4096, crashed during a long news feed, destroying all file systems. Previous to the big crash (I now run Xenix/386, as does my feed), "double panics" were a routine event on V/AT. Virtually everyone I know who uses/used V/AT with active tty processes has experienced the same problem, and this includes a couple of genuine Big Blue machines. The problem is known and was easily replicated in 2.2... just login with a 9600 baud machine over a null modem and then upload a text file with 'cat > filename'. Then fire up 'cu' (providing that you're not already staring at a screen with Microport's guts spilled all over it). -- +----- + Steve Manes Roxy Recorders, Inc. NYC + decvax!philabs!cmcl2!hombre!magpie!manes Magpie BBS: 212-420-0527 + SmartMail: manes@magpie.MASA.COM
jjw@igloo.UUCP (John Welch) (02/06/88)
In article <434@cimcor.UUCP> mike@cimcor.UUCP (Michael Grenier) writes: >at a lower priority. I have catted (sp?) large text files without >any problem while news was unpacking, at the same time as my wife >was working on the 9600 baud vt200 terminal. Sorry if I gave the impression that the bug occurrs while UNPACKING. It happens while news is being TRANSMITTED... It appears that Microport has interrupts turned off for far too long while inside the interrupt service routines. The particular problem here happens on a CGA card, and it is quite a bit worse if you use the un-flicker option, which appears to leave interrupts disabled while scrolling during a screen refresh. -- ========================================================================== John Welch ..{codas,ihnp4}!ddsw1!igloo!jjw "I will not be pushed, filed, stamped, indexed, briefed, de-briefed or numbered. My life is my own; I am a free man!" - #6
learn@igloo.UUCP (william vajk) (02/06/88)
In article <434@cimcor.UUCP>, mike@cimcor.UUCP (Michael Grenier) writes: > You mentioned an improvement going from the 65ms drives to the 40ms drives. > Perhaps the reason for my success is my faster 28ms drives (maxtor 1140). > I've had this system running since I installed version 2.3 with dosMerge > for a couple months now without any crash at all. Maybe Microport > isn't robust for all hardware configurations but it sures works good > on this one. Most of the system crashes disappeared with the installation of 2.3. The ones that remain are the direct result of hung processes when a remote user terminates the session without logging off. This usually results in the OS becoming confused, DTR not being reasserted, and any attempt to respawn getty ends with a completely hung system and a double panic. From that standpoint, great strides have been made by microport. The upgrade of drives has relieved the previously undiagnosed problem of dropping the uucp feed with an input mode failure when the system was otherwise idle, the error message being identical to the failures reported when ths system is not idle during incoming uucp. Unless the system is otherwise idle *during* incoming uucp, there are sufficient dropped characters to generate alarms terminating the uucp. Actually, you don't need a long feed to prove this one way or another for your system. A 75 to 100 K feed will suffice, if you cat a long file during the feed, either from one of the consoles or by remote. The problem is greatest if the remote operates at 300 baud as the continuous screen refresh steals the interrupt necessary for the incoming uucp to function. This history was completely valid until a few days ago, when we installed a telebit trailblazer and started receiving our newsfeed at 9600 baud. What has changed is that the manifestation is now reversed for reasons we have yet to discern. Watching an incoming uucp (usenet news), I permitted a user to log in at 300 baud, and cat a long file. The packets at 9600 come across fast enough, and there are other intelligent interactions between the corresponding modems. What previously was an uninterrupted stream of data going out the 300 baud line (while uucp died) is now a clearly interrupted stream to the 300 baud line, 180 degrees out of sync with the RD light on the telebit. Karl Denninger's autobaud getty was installed to accommodate the 9600 baud modem connection. Our original hunch of problems with interrupt prioritazation seems to be reproved at every turn. Once this is fixed, the remainder should fall neatly into place. Changing the main drive from a 40 meg 40 ms to a 72 meg, 28 ms unit had no effect on uucp problems. We maintain a separate drive with a single partition for /usr/spool. Bill Vajk learn@igloo
rbradbur@oracle.UUCP (Robert Bradbury) (02/14/88)
Over the last month I've seen alot of bad press about the speed of Microport UNIX. It started with the Unique article which in my opinion gave an excessively negative imaage of Microport UNIX and has continued here. The basic issue seems to revolve around the speed of the two systems as related to disk I/O and serial port I/O. Unfortunately people seem to be describing symptoms and complaining instead of actually doing some hard research into the nature of the problems. RE: hard disk speed. Has anyone done the research to determine the proper interleave factor for the hard disks? Has anyone determined the interaction between the software interleave (specified during when making UNIX file systems) and hardware interleave handled by the controller? Exactly what are the I/O transfer rates you can expect under UNIX? RE: serial I/O ports. I'm under the impression that standard PC I/O ports do character at a time I/O. That means you have to take an interrupt for every character into or out of the machine. What is the interrupt overhead on the UNIXes? I once managed a VAX with a DZ multiplexor (which did character at a time I/O) and we could routinely bring the machine to its knees by running a couple of lines doing medium speed I/O. Unless you have very fast machines with low interrupt overhead you cannot expect to do much I/O with character at a time devices. If you want to do alot of I/O and not bog down the CPU go get a board like the DIGIBOARD COM/8I with another processor (80186) and 8K I/O buffers to handle the I/O. I'm not saying that XENIX is not faster than Microport, after all SCO/ Microsoft has had 2-3 more years to refine the serial I/O port driver and hard disk interleave factors. The fact that most XENIX development was done of VERY SLOW machines gave the developers an incentive to improve those features. Now people have so much CPU power available to them that they rarely put themselves in an environment which degrades peformance sufficiently to provide an incentive to improve things. One of the advantages of Microport over Xenix is that it provides tools to analyze the performance of the machine (SAR and the system profiler). SAR works. A sequence like the following: /usr/lib/sa/sa1 - execute command(s) /usr/lib/sa/sa1 sar -y - give tty I/O statistics sar -b - give disk I/O statistics These would give us (and Microport) an idea of how heavily the system is being used and what the bottlenecks might be. The system profiler would provide even more information about exactly which functions in the UNIX kernel were consuming the most time. (Unfortunately it appears the profiler is not operative in my current 2.2 release of 386 Unix -- -2 for Microport). As these features are not available under Xenix (remember the Xenix kernel is based on System III) you have no assistance in locating the source of system bottlenecks. I would be interested in some HARD facts about how many terminals you can run at what speeds with and without console I/O, hard disk interleave factors, interrupt overhead, I/O bandwidth, etc. for machines running Microport UNIX and XENIX. Then we could give the O.S. and the machines a "FAIR" comparison. Should we develop a set of programs which can measure these things? I'm willing to provide the database maintenance for the results. -- Robert Bradbury Oracle Corporation (206) 784-9726 hplabs!oracle!rbradbur
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (02/17/88)
In article <242@oracle.UUCP> rbradbur@oracle.UUCP (Robert Bradbury) writes: | [...] | I'm not saying that XENIX is not faster than Microport, after all SCO/ | Microsoft has had 2-3 more years to refine the serial I/O port driver | and hard disk interleave factors. The fact that most XENIX development I have *never* heard of a problem with Xenix crashing because someone was doing serial i/o. Until Microport 2.3, a number of people (all three of the people I know who have it and dozens on the net) had problems. I measured the serial throughput and the best I could get was 102cps at 1200 baud, system crashed at higher speeds. | was done of VERY SLOW machines gave the developers an incentive to | improve those features. Now people have so much CPU power available | to them that they rarely put themselves in an environment which degrades | peformance sufficiently to provide an incentive to improve things. What Cray are you using? I have a *lot* of incentive to keep things working well. | [...] | As these features are not available under Xenix (remember the Xenix | kernel is based on System III) you have no assistance in locating | the source of system bottlenecks. I'm not sure what the connection is... these tools seem to run under Xenix if you have a source license. SCO didn't bundle them. MicroPort didn't bundle acctcom. My understanding is that Xenix passed all but six programs of SVVS (does anyone else have solid information otherwise?) and since the SysV kernel is based on the SysIII kernel, I think it's safe to assume that the MicroPort kernel is SysIII based, also. | [...] | Should we develop a set of programs which can measure these things? | I'm willing to provide the database maintenance for the results. A large number of people have measured these things, the trick is to pick the benchmark that says what you want it to. Not that what you propose is without merit, but the only way it would be valid would be to run both operating systems on the same machine. I am a believer that "identical hardware isn't." -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
learn@igloo.UUCP (william vajk) (02/19/88)
In article <242@oracle.UUCP>, rbradbur@oracle.UUCP (Robert Bradbury) writes: > Over the last month I've seen alot of bad press about the speed of > Microport UNIX. It started with the Unique article which in my > opinion gave an excessively negative imaage of Microport UNIX and > has continued here. I don't know how to break the news to you, but this started well before any _Unique_ article. Looking at the referenced articles list, I note that two of them in this ongoing discussion originated from igloo. If you want an image which reflects the true state of microport, I invite you here, to Northbrook Illinois, to be sysadm for igloo for a week. I am discussing the '286 product here. > The basic issue seems to revolve around the speed > of the two systems as related to disk I/O and serial port I/O. > Unfortunately people seem to be describing symptoms and complaining > instead of actually doing some hard research into the nature of > the problems. I am the consumer, the end user of the product. Yes, I can complain in terms of sympotms all I want. I paid for that right. I have done as much research as is possible for an end user to do (we are not a development lab here....how many end users are ?) and relayed all available information to microport. It is the OEM's job to do the hard basic research. Are you suggesting that we, the users, fix the product for them ? Why, then, would we need an OEM at all ? > RE: hard disk speed. Has anyone done the research to determine the > proper interleave factor for the hard disks? Has anyone determined the > interaction between the software interleave (specified during when > making UNIX file systems) and hardware interleave handled by the > controller? Exactly what are the I/O transfer rates you can > expect under UNIX? The transfer rates affect the amount of time that interrupts remain (get this) disabled. I have already noted that with a slow HD, we lost some uucp connections during extended feeds. This problem went away when the drive for /usr/spool was upgraded to a fast drive. When the slow drive captured the interrupt, and the host computer continued to send, igloo was unable to return a checksum, as the interrupt was occupied with the HD, sometimes long enough to have the host time out and drop the feed. > DIGIBOARD COM/8I with another processor (80186) and 8K I/O buffers > to handle the I/O. a hardware solution to a software problem ? Gack ! What next ? > I'm not saying that XENIX is not faster than Microport, after all SCO/ > Microsoft has had 2-3 more years to refine the serial I/O port driver > and hard disk interleave factors. The fact that most XENIX development > was done of VERY SLOW machines gave the developers an incentive to > improve those features. Now people have so much CPU power available > to them that they rarely put themselves in an environment which degrades > peformance sufficiently to provide an incentive to improve things. Interesting you should bring up this point. Microport did promise a *working* product. That means, it is supposed to do unixish things, like uucp, and it does not perform these functions in an acceptable manner, by *anyone's* yardstick. Slow machine vs fast machine for development has no bearing. Microport was developed on a fast machine, for fast machines, and does not function as it is supposed to. CPU power ? We ran microport on a 20 mhz '386 machine loaned to us for a weekend. Yep, stuff zipped along quite nicely, but essentially nothing changed when it came to getting our newsfeed. It still failed miserably. There was essentially no difference during uucp between the 8 mhz '286 machine we normally run, and the '386 20 mhz system. The poll still failed simply by having either the console, or one user at 2400 baud cat a large file. Fails even faster if the user catting a large file is at 300 baud. > One of the advantages of Microport over Xenix is that it provides tools > to analyze the performance of the machine (SAR and the system profiler). > SAR works. A sequence like the following: > /usr/lib/sa/sa1 > - execute command(s) > /usr/lib/sa/sa1 > sar -y - give tty I/O statistics > sar -b - give disk I/O statistics > > These would give us (and Microport) an idea of how heavily the system > is being used and what the bottlenecks might be. I believe microport has a lab capable of doing this. I have neither the time nor the patience. I offered microport officials root privledges on igloo, and a uucp connection, if they wanted to come play with this box. > I would be interested in some HARD facts about how many terminals > you can run at what speeds with and without console I/O, hard disk > interleave factors, interrupt overhead, I/O bandwidth, etc. for > machines running Microport UNIX and XENIX. Then we could give > the O.S. and the machines a "FAIR" comparison. During 2400 baud (and slower) uucp, you can run no terminals, no remote logins, and no console, else you lose the feed because of the lost character problem, which then results in checksum problems.... With Karl Deninger's autobaud getty in place, and with a 9600 poll, the losses of incoming uucp become short enough that we do not lose the feed. The transfer time is greatly extended however, and characters are lost with a user attempting to type in into mail (as in elm running vi.) Also, a user attempting to cat a file at 300/1200/2400 gets a jumpy interrupted stream. I consider the jumpy stream acceptable, though it does look quite strange. I am not interested in comparisons. I am interested in a *working* system. I wouldn't mind losing some speed, if it worked. I can counter that with faster hardware. I don't consider lost characters to be acceptable. I don't consider feeds lost because of a malfunctioning OS to be acceptable. > Should we develop a set of programs which can measure these things? > I'm willing to provide the database maintenance for the results. I have full system accounting running at igloo presently, the problems predated the installation of accounting. Send me mail. If you're really interested in solving microport's problems, I'll gladly set up an account for you on igloo. I am interested in having a working product. I don't know about devoting scads of additional time to solve the OEM's problems for them, but I'll continue to contribute what I consider 'reasonable'. Bill Vajk learn@igloo