[comp.sys.att] DOS Tasks under Unix: Let's hear about it!

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.