gas@ecsvax.UUCP (Guerry A. Semones) (05/19/88)
Okay folks, AT&T's 386 based unix for their work group series has been available for a short while. Sun has announced and begun to ship their 386i Roadrunner series. We're starting to see more and more 386 based machines running unix with dos as a subtask. Some of us have these machines. Some of us have only seen the demos. And some of us have only Heard about them. How about some of you that have the fortune/misfortune (?) to have this type of setup, let us know what you have been able to do with these machines. Several questions come to mind. I've heard bunches about com- patibility, ie. will it run lotus, flight simulator, etc? But how about that all important question: How fast does the dos subtask perform? Has someone tryed putting a large dos application up as a dos subtask to Unix and seeing how well it performs? Perhaps a massive system like PC-SAS, or some other memory-hungry, large database system? I'd like to know your impressions of how well the dos subtasks perform, and what kinds of performance impacts you have seen. If any of you who have this equipment could do this it would be greatly appreciated by those of us who are investigating getting some of this type of systems. Thanks in advance for your insights.... -- Guerry A. Semones BITNET: drogo@tucc.BITNET Information Services USENET: gas@ecsvax Duke University My views are despairingly mine only. Talent Identification Program "We ain't gifted, we just work here."
mmengel@cuuxb.ATT.COM (~XT4103000~Marc Mengel~C25~G25~6184~) (05/19/88)
In article <5090@ecsvax.UUCP> gas@ecsvax.UUCP (Guerry A. Semones) writes: >Okay folks, AT&T's 386 based unix for their work group series has >been available for a short while. Sun has announced and begun to >ship their 386i Roadrunner series. We're starting to see more and >more 386 based machines running unix with dos as a subtask. Some >of us have these machines. Some of us have only seen the demos. >And some of us have only Heard about them. > How about some of you that have the fortune/misfortune (?) to >have this type of setup, let us know what you have been able to do >with these machines. There are two major "Dos under Unix" products on the market -- VP/ix from Phoenix (a.k.a Simultask-386 from AT&T, etc.) and OS/Merge from Locus. I am only familiar with the VP/ix based product from AT&T, and all of my comments below refer to it. First a little background -- VP/ix provides a virtual IBM PC with floppy drives, a C: and D: hard drive, and the Unix file system as a NETBIOS network shared drive. You have a video adaptor -- either whatever is on your console if you run on the console, or a Monochrome adaptor card if you run it from a serial port. Virtual DOS devices can be mapped to unix files/devices via a config file. Note that there is *no* relationship between devices in your (physical) machine and devices accessable in your (virtual) DOS emulation. (well ,except for video adaptor on the console). > Several questions come to mind. I've heard bunches about com- >patibility, ie. will it run lotus, flight simulator, etc? Yes, and yes. The only packages I know of that don't run are Copywrite and version 1.0 of Enable (later Enable versions work). The list of applications tested is over 50 items long. Pretty much evrybody's favorites (Lotus, Word Perfect, Symphony, etc.) have been tested and work quite well. Flight simulator does run on the console (but not on remote ascii terminals, for obvious reasons). >But how >about that all important question: How fast does the dos subtask >perform? Well, now that gets kinda weird. You see, some things are faster (disk i/o is buffered by UNIX, for example), but programs that count to 10000 to delay 0.5 seconds get very different response under Simultask386-VP/ix. Also, if you are running text applications from a remote ascii terminal, screen updates and keyboard activity take place at whatever baudrate your terminal runs at, which can seem awfully slow, esp. dialed up at 2400 baud... Other wierdness is that the most efficient way to do things under Simultask386-VP/ix is to use DOS interrupts or BIOS interrupts, whereas any dyed-in-the wool DOS hacker will tell you you can do serial i/o faster by hand-coding and directly accessing the UART, similarly for running the floppy, etc. Twiddling hardware registers *works* under VP/ix-Simultask386, but is slower since it must be *emulated*. > Has someone tryed putting a large dos application up as a dos >subtask to Unix and seeing how well it performs? Perhaps a massive >system like PC-SAS, or some other memory-hungry, large database >system? I haven't... > I'd like to know your impressions of how well the dos subtasks >perform, and what kinds of performance impacts you have seen. well, as mentioned above, some things are faster, some slower. Unix scheduling tends to lower priorities on CPU bound tasks, so that with several users using the machine, the mapping from wall clock time for a long computation (by computation I mean CPU bound,no i/o, etc.) under DOS to VP/ix-Simultask386 goes roughly exponential. That is, if it sits for an hour or two just computing under DOS (with no i/o -- Unix bumps your priority back up when you wait for I/O) , it will take a LONG TIME under Unix, something that takes under 1 minute on a PC/XT will take about the same time under Simultask386-VP/ix. Programs that do sequential file I/O will be very happy, however,since the Unix buffer cache pre-fetches sequential reads. The Norton SI utility gives some extremely impressive numbers for performance, which are not representative of actual use due mainly to the small size of the test (it doesn't run long enough for the scheduling concerns to become an issue, and its disk i/o all gets handled by the buffer cache, so it really cooks). The bottom line is, on the average, the performance under VP/ix-Simultask386 with 2 users seems about that of an 8 MHz PC/AT, but the variance is *very* large depending on the sort of work the program does. Possibly just as important, however, is that it doesn't kill the performance of the rest of the system to have a few DOS tasks running. (I have not yet done testing with a large numbe of DOS tasks.) > If any of you who have this equipment could do this it would be >greatly appreciated by those of us who are investigating getting some >of this type of systems. > Thanks in advance for your insights.... >-- > Guerry A. Semones BITNET: drogo@tucc.BITNET > Information Services USENET: gas@ecsvax > Duke University My views are despairingly mine only. > Talent Identification Program "We ain't gifted, we just work here." -- Marc Mengel attmail!mmengel ...!{moss|lll-crg|mtune|ihnp4}!cuuxb!mmengel
les@chinet.UUCP (Leslie Mikesell) (05/20/88)
>First a little background -- VP/ix provides a virtual IBM PC >with floppy drives, a C: and D: hard drive, and the Unix file >system as a NETBIOS network shared drive. You have a video >adaptor -- either whatever is on your console if you run on the console, >or a Monochrome adaptor card if you run it from a serial port. >Virtual DOS devices can be mapped to unix files/devices via a >config file. Can anyone say how much of a Netbios interface is presented by VP/ix? In limited testing I have found that 2 Dos versions of kermit 2.30 (which can talk across a real netbios network) cannot connect to each other under VP/ix. More surprising, Microsoft word and chart, which know how to release print jobs on a real network, do not do so under VP/ix. You have to pop up the control menu and manually force the print jobs to be passed to the unix spooler. Perhaps I missed something in the setup? Les Mikesell
mmengel@cuuxb.ATT.COM (~XT4103000~Marc Mengel~C25~G25~6184~) (05/20/88)
In article <5622@chinet.UUCP> les@chinet.UUCP (Leslie Mikesell) writes:
$>First a little background -- VP/ix provides a virtual IBM PC
$>with floppy drives, a C: and D: hard drive, and the Unix file
$>system as a NETBIOS network shared drive. You have a video
$>adaptor -- either whatever is on your console if you run on the console,
$>or a Monochrome adaptor card if you run it from a serial port.
$>Virtual DOS devices can be mapped to unix files/devices via a
$>config file.
$
$Can anyone say how much of a Netbios interface is presented by VP/ix?
$In limited testing I have found that 2 Dos versions of kermit 2.30
$(which can talk across a real netbios network) cannot connect to
$each other under VP/ix. More surprising, Microsoft word and chart,
$which know how to release print jobs on a real network, do not do so under
$VP/ix. You have to pop up the control menu and manually force the
$print jobs to be passed to the unix spooler. Perhaps I missed something
$in the setup?
Perhaps I was not clear here -- you are provided with a *redirector*
which acts like a NETBIOS redirector; you are not provided with a
full Netbios emulation.
$ Les Mikesell
--
Marc Mengel
attmail!mmengel
...!{moss|lll-crg|mtune|ihnp4}!cuuxb!mmengel
bill@carpet.WLK.COM (Bill Kennedy) (05/22/88)
In article <1791@cuuxb.ATT.COM> mmengel@cuuxb.UUCP (PUT YOUR NAME HERE) writes: >In article <5090@ecsvax.UUCP> gas@ecsvax.UUCP (Guerry A. Semones) writes: >>Okay folks, AT&T's 386 based unix for their work group series has >>been available for a short while. Sun has announced and begun to [ lots deleted about VP/ix, I am following up for Microport Merge/386 ] >> Thanks in advance for your insights.... >>-- >> Guerry A. Semones BITNET: drogo@tucc.BITNET >> Information Services USENET: gas@ecsvax > >-- > Marc Mengel > > attmail!mmengel > ...!{moss|lll-crg|mtune|ihnp4}!cuuxb!mmengel I am very interested in Marc's report on VP/ix aka Simul-Task 386. I am very familiar with Simul-Task for the AT&T PC 6300 PLUS (no fair comparison possible other than its overall reliability) and casually acquainted with VP/ix for SCO Xenix (still in "controlled release"). I regret to report that I am intimately familiar with Merge/386 from Locus/Microport. Before anyone jumps to the conclusion that this is irrational flaming, stop and think about how frustrated you get when you install a product that breaks your *entire* system, *all* of it. The happiest I have ever been with the Microport product was when the UPS driver carried it away, given to a rather nice fellow who didn't deserve what he thought was a favor. The Microport "product" (I shouldn't dignify it by calling it that) is just not ready for market. It has a number of quirks from which the only recovery is a low level format on the hard disk. I became quite expert at that. Before I proceed I must emphasize I am referring to the _386_ implementation, I'm ignorant of the 286 version. Even more annoying than it's fickle nature and appetite for super blocks is the vendor's cavalier attitude towards the purchaser. It is clearly marked as a beta test version (though the price sheet and advertising is silent about that) but it sells for full retail. There are fixes that have been tested and confirmed but Microport "does not issue replacement beta products for a beta product" (their words, not mine). There are serious flaws in the Merge kernel, both on the UNIX and the DOS sides. Many of the UNIX problems go away by removing the Merge kernel so I have no reason to believe that they are present in the UNIX only kernel (its problems are not pertinent to this discussion). One modest example... If you assign a resource to DOS (COM1 for Crosstalk) it gets correctly relinquished by UNIX but never picked up by DOS. The result is that when you return to UNIX, that device is gone forever (can't be freed by DOS, it was never inherited), reset the machine. The Merge kernel can and does panic rather frequently for various reasons, some of which scribble all over the super block. Since the entire file system is corrupt at that point the recovery is to re-install which means low level format the hard disk. I was told that the format could be bypassed but was never successful in doing so. If the kernel panics during an fsck necessitated by an earlier panic, that seems to be the end of everything. There are some device drivers that will work just fine on a pure UNIX kernel that will seriously aggravate the already fragile nature of the Merge kernel. The lp driver is broken on the UNIX side (they put a line counter in the _driver_, not the filter!) and when you try to print something on the DOS side things get much worse. If you plug and unplug the printer (in this case an HP Laser Jet-II or an Okidata 2350) quickly enough you can get a line out for each unplug-replug sequence. I got so desparate to get something out that I almost got used to that. You get some odd reactions from people who see you doing it... You can cause DOS to sign on to a remote serial terminal. That is exciting and it makes you want more. I have a very simplistic program, written in Aztec C that takes the running time of a TV movie and tells you how many minutes to record on long and short play speed so it fits on a 2 hr tape. I don't know if it was the floating point arithmetic, the fgets, or the printf, but it crashed the emulator and the process' priority downgraded so much and so fast that I could not kill it with -9. The program runs flawlessly under Simul-Task 286 (ironically also a Locus effort) and plain old DOS. Even more curious was that it would run flawlessly on the console. Perhaps if it used something exotic like curses or something it might run on a serial terminal but fgets/printf seem to make it want to crash. I was never able to try a bulky or resource hungry program under Merge/386 because it wouldn't stay up long enough to get any meaningful results. Nor was I able to test any of the nifty disk file gymnastics they provide because I could not keep the file system intact long enough to get around to trying them. The documentation is misleading, incomplete, and repetitive of the marketing hype, woefully lacking in accurate technical content. Aside from the above nit picking, I would not hesitate to recommend the "product" to a competitor I thought might not prosecute me for industrial sabotage. Sorry for the bulk, I wanted my description to be complete enough to convince the reader that I gave it a full court press, not just a quick try and bad rap. I can offer one Simul-Task 386 observation. Microport has virtual consoles in V/386 (and V/AT that I'm using right now). If something goes terribly awry you can ALT-Function key and go to another console to kill/recover. The AT&T 386 UNIX has no such capability so if you should run up a dead end street your reset button (and fsck) will get a lot more exercise. I can not complain that it's needed, I don't have the AT&T product, I'm suggesting that if it is needed, you have a better chance for recovery with virtual consoles. Oddly enough their 286 offering for the 6300 PLUS has a similar capability and the ISC port from which they derived 386 UNIX has them, I'm not sure why they removed them. I'm still curious. Sorry, I need to add a last item. The *same* hardware, no change to anything, runs SCO Xenix 386 and AT&T 386 UNIX flawlessly and ran the Microport 286 product, V/AT flawlessly before I tried V/386. Even if grief is free and you enjoy installing things, for the money, V/386 and particularly Merge/386 (in my non-legal opinion) borders on fraud. -- Bill Kennedy Internet: bill@ssbn.WLK.COM Usenet: { rutgers | cbosgd | ihnp4!petro }!ssbn!bill
keithe@tekgvs.TEK.COM (Keith Ericson) (05/24/88)
> > Twiddling hardware registers *works* under >VP/ix-Simultask386, but is slower since it must be *emulated*. > I tried installing PC-NFS under VP/ix (well, it's like this: I had a network interface card that PC-NFS would drive (an NI5010) and none that VP/ix a la' Micom-Interlan would drive an NP-600) ) and no matter what I did the diagnostics kept coming back saying it couldn't find the interface card at the address I was telling it to use. I assumed it was getting mapped to someplace else. Perhaps it was just timing out? keith
mmengel@cuuxb.ATT.COM (~XT4103000~Marc Mengel~C25~G25~6184~) (05/24/88)
In article <3488@tekgvs.TEK.COM> keithe@tekgvs.UUCP (Keith Ericson) writes: >> Twiddling hardware registers *works* under >>VP/ix-Simultask386, but is slower since it must be *emulated*. >I tried installing PC-NFS under VP/ix (well, it's like this: I had a >network interface card that PC-NFS would drive (an NI5010) and none that >VP/ix a la' Micom-Interlan would drive an NP-600) ) and no matter what >I did the diagnostics kept coming back saying it couldn't find the >interface card at the address I was telling it to use. I assumed it was >getting mapped to someplace else. Perhaps it was just timing out? No... The only hardware registers that are emulated are the ones hard coded into the emulation -- the floppy controller, serial interface (COM1:) interrupt controller, etc. You see only the "hardware" provided by the emulation, not what is in the machine. For example, in the config file you can tell Simultask-VP/ix that floppy drive B: should be mapped onto the file /tmp/floppyb. You can then start up the dos emulation and work with floppy drive B: *even if you have no second floppy drive in your machine*. The drive B: here is complete fiction provided by the DOS emulation -- as are *all* of the emulated devices. Some of them just *happen* to get mapped onto real devices. -- Marc Mengel attmail!mmengel {lll-crg|mtune|ihnp4}!cuuxb!mmengel
kc@rna.UUCP (Kaare Christian) (05/26/88)
> Guerry A. Semones: > Okay folks, AT&T's 386 based unix for their work group series has > been available for a short while. Sun has announced and begun to > ship their 386i Roadrunner series. We're starting to see more and > more 386 based machines running unix with dos as a subtask. Some > of us have these machines. Some of us have only seen the demos. > And some of us have only Heard about them. > How about some of you that have the fortune/misfortune (?) to > have this type of setup, let us know what you have been able to do > with these machines. I have a DataBank 386 @ 20 MHZ with 2MB of memory. It doesn't use cache, and it seems to be 10-15% slower than the fastest 20MHZ 386 machines, such as the Compaq and the Proteus. My 30 MB hard disk is half Xenix/VPix, half DOS. Xenix is rock solid, I've never had a crash. VPix is called a "controlled" release, and it seems much less solid. The only software that I've used with VPix is Microsoft C and Lotus Manuscript, plus a bunch of small utilities and software that I have developed. Everything works fine. Speed of DOS apps running under VPix seems the same as when running under dos. I ran the dhrystone benchmark under vpix, and under pure dos: NoReg Registers DOS 5952 6172 Xenix/VPix/DOS 5882 6024 The minor difference could be the VPix artifact, but it also could be due to differences in clock accuracy, or the general variability of dhrystones. In general, I don't use Dhrystones to make distinctions of less than about 10 percent. Installation was partly easy, and parlty difficult. The software is set up so that it will automatically build a new kernel, and it does most other chores. But after installation you still have to do some permissions fixing, and other miscellaneous chores that are discussed in a couple of different parts of the manual. It required one call to support before I had things ok. An InfoWorld review griped that VPix wouldn't correctly run 1-2-3. I haven't tried 1-2-3, but I haven't experienced anything similar to what InfoWorld reported. I haven't tried any graphics apps, and I haven't tried to run VPix on a supported terminal. But as a tool to let me run dos from within the Xenix environment, it has worked fine. (My needs are modest, but it nicely meets those needs.) Last week I demoed a Sun 386i for a couple of hours. Its dos apps come up in windows on the Sun display, rather than the screen switching (sco calls it MultiScreens(tm)) technique used in Xenix/VPix. Text based stuff seemed to work fine, and at normal speed. Graphics stuff switched to a different window shape (2x1 aspect ratio, just like the cga aspect ratio) and then seemed to run sluggishly. They worked, but I don't know if you would really want to use them. The 386i was always busy, with a load average of more than one even when we weren't doing anything. The tech support person didn't seem too concerned, but getting rid of whatever was causing that load might have made the graphics stuff work faster. I ran dhrystones on the machine under dos, and got a figure of about 6000, but I don't think it is valid beccause the machine wasn't idle. I also ran some standard Unix chores on the 386i. The machine wasn't idle, but it wasn't as busy as during the dos work. nroff -ms /dev/null 1 real grep zoom /usr/dict words 1.6 real The first result is about 4x faster than a VAX/780, the second is about 2.5x faster than a VAX/780. I didn't do anything to test compute bound stuff or to test floating point. Kaare Christian Research Assoc., The Rockefeller Univ.