[comp.sys.ibm.pc] Microport 386 UNIX 5.3 Rel 2.1 speed questions

bradbury@oracle.UUCP (Robert Bradbury) (11/17/87)

I've just installed Microport Unix 5.3 Rel 2.1 on my Compaq 386.
I'm puzzled about the speed of the machine.  Microport UNIX 5.2
on the 386 (in 286 mode) gives a Drystone rating of 3275 with
the UNIX compiler and 3500 with the Metaware compiler.  The 5.3
release in 386 mode gives a Drystone rating of 1652 (no-reg)
and 1773 (reg).

Why does the 386 run slower than the 286?

Another test:
	time cat < /dev/null
gives a real time of .2 sec on the 286 and .4 sec on the 386.
I thought this might be due to virtual memory/shared library
overhead but the drystone results indicate that the 386 is slower
for compute-bound operations.

My drystone results were even worse before I discovered they
had changed HZ to 100 on the 386 (from 60 on the 286).
(The interesting question is whether the times() call returns
 60 HZ ticks for 286 programs running on the 386 (or whether
 upwards compatibility is a pipe-dream).)

My general impression is that the 386 release "seems" slower.
Has anyone else found this to be true and are there any
explanations?  Is this a general problem with 5.3?
Could it be related to shared libraries or virtual memory
or does it involve the 80386 architecture in some way?

Does anyone have any comparisons of 286 vs 386 Xenix or
Interactive Systems UNIX?

-- 
Robert Bradbury
Oracle Corporation
(206) 364-1442                            hplabs!oracle!bradbury

bradbury@oracle.UUCP (Robert Bradbury) (11/18/87)

It turns out that you have to force Compaq 386 machines (and perhaps others)
to operate in "fast" (16Mhz) mode when running UNIX 5.3 from Microport.
This requires flipping a switch on the mother board and was mentioned
(in small print) in the Microport release notes.  When I asked Microport
support about the problem they indicated that they knew the 386 was slow
and didn't mention the variable speed problem (-2 for support).
Microport's development staff should lose a few points for requiring
you to hardwire high speed operation (which disables some functionality
under DOS) and for releasing an O.S. which runs 3 times slower than it
could and doesn't warn you of the fact.  My thanks to the fellow net
readers who actually phoned me to let me know about the problem.

The numbers now indicate that:
    time cat < /dev/null: .2 sec
    386 Drystones are: 3903 (NOREG) 4226 (REG)
    286 Drystones (under 386 mode): 1953 (UNIX cc) 2093 (Metaware CC)
        Adjusting for the 60 -> 100 Hz problem yields 3254 and 3488
	which is very close to what they were under 286 UNIX.

I ran some other tests and they indicate that there is little or no
penalty in running 286 programs on the 386.   CPU intensive programs
are virtually the same and system call intensive programs are perhaps
10-20% slower.

I apologize if I raised any concerns among current or future Microport
386 users about product performance.  Once you get the speed of the
machine correct it seems to perform just about where I would expect
it to perform.  For comparison a Sun 3/160 benchmarks at 2800-3200 Drystones.

-- 
Robert Bradbury
Oracle Corporation
(206) 364-1442                            hplabs!oracle!bradbury

dougm@ico.UUCP (11/20/87)

In article <346@oracle.UUCP> bradbury@oracle.UUCP (Robert Bradbury) writes:
>I've just installed Microport Unix 5.3 Rel 2.1 on my Compaq 386.
>I'm puzzled about the speed of the machine.  Microport UNIX 5.2
>on the 386 (in 286 mode) gives a Drystone rating of 3275 with
>the UNIX compiler and 3500 with the Metaware compiler.  The 5.3
>release in 386 mode gives a Drystone rating of 1652 (no-reg)
>and 1773 (reg).
>
>Why does the 386 run slower than the 286?

Probably has nothing to do with the Microport software.

Have you set the processor speed switch on the Compaq to high rather
than the "auto" mode it comes set to by default?  The switch is on the
motherboard and made a big difference in performance on the one I am
using.

			Doug McCallum
			Interactive Systems
			dougm@ico.isc.com

eric@snark.UUCP (Eric S. Raymond) (11/22/87)

In article <2001@ico.UUCP>, dougm@ico.UUCP (Doug McCallum) writes:
> Have you set the processor speed switch on the Compaq to high rather
> than the "auto" mode it comes set to by default?

I have a box called a Vesta that is essentially a Compaq 386 clone, with the 
100ns SCRAMS and all; and I run Microport UNIX 5.3 for the 386 on it. So the
moment I heard about this problem I checked...

...and the Vesta has no speed switch. Instead, it boots up in fast mode. They
give you a (DOS) program called SETSPEED.EXE for slowing it down to the
equivalent of Compaq 'auto' mode.

Interestingly, the manufacturer's tech guy told me over the phone that this
isn't because the floppy drives won't format in high mode (the reason for some
other similar utilities I've seen), but because lotsa customers wanted to run
Flight Simulator etc. and got upset when the suckers ran like they were on a
megadose of speed...

BTW, I have 5.3 DOSMerge and it is *NEAT*. Separate file system? What separate
file system? You keep your DOS cruft in a UNIX directory and run it from a
normal sh -- the kernel task loader does the rest, even to hooking up stdin/
stdio and the comm and printer ports correctly. It has been quite some time
since I've been as impressed by any software product as I am by this one,
even though I knew it was theoretically possible. They make it look easy!
-- 
      Eric S. Raymond
      UUCP:  {{seismo,ihnp4,rutgers}!cbmvax,sdcrdcf!burdvax,vu-vlsi}!snark!eric
      Post:  22 South Warren Avenue, Malvern, PA 19355    Phone: (215)-296-5718

greg@xios.XIOS.UUCP (Greg Franks) (11/24/87)

In article <346@oracle.UUCP> bradbury@oracle.UUCP (Robert Bradbury) writes:
>Why does the 386 run slower than the 286?
[timings of 'cat'ing deleted].

Beware: A fast CPU does not necessarily imply a fast computer.  There
are other factors: for example, how fast are the disks? An 8088 loading
off a RAM disk is going to be a lot faster for 'time cat < /dev/null'
than an 80386 running off of floppies! One other consideration: is 'cat'
loaded into the file system cache and/or does it have the sticky bit
on?.  Microport 5.2.2 for the 286 uses an awfully big file system cache. 

Regarding dhrystones: the results you post do seem very strange.  The
periodic dhrystone postings that appear in comp.arch show the 80386's to
have quite an impressive rating.  Perhaps the compiler that you are
using is a piece of junk.  Does anyone know if Green Hills has a 386
compiler out yet? On the other hand, perhaps the 386 compiler you are
using isn't optimizing dhrystones down to:

main()
{
	long t1, t2, time();
	t1 = time(); t2 = time();
	printf( "%ld\n", t2 - t1 ); 
}

:-) :-) :-) :-) :-) 

Keep poking around and good luck!
-- 
Greg Franks             XIOS Systems Corporation, 1600 Carling Avenue,
(613) 725-5411          Ottawa, Ontario, Canada, K1Z 8R8
utzoo!dciem!nrcaer!xios!greg    "There's so much to sea in Nova Scotia"

jmsully@admin.UUCP (John M. Sully) (11/30/87)

In article <346@oracle.UUCP> bradbury@oracle.UUCP (Robert Bradbury) writes:
|I've just installed Microport Unix 5.3 Rel 2.1 on my Compaq 386.
|I'm puzzled about the speed of the machine.  Microport UNIX 5.2
|on the 386 (in 286 mode) gives a Drystone rating of 3275 with
|the UNIX compiler and 3500 with the Metaware compiler.  The 5.3
|release in 386 mode gives a Drystone rating of 1652 (no-reg)
|and 1773 (reg).

This problem might be caused because the system is running a 8Mhz instead
of 16Mhz.  Set SW-4 on the motherboard to off to force the system to boot
at 16Mhz.

mike@cimcor.UUCP (Michael Grenier) (12/02/87)

In article <166@admin.UUCP>, jmsully@admin.UUCP (John M. Sully) writes:
> In article <346@oracle.UUCP> bradbury@oracle.UUCP (Robert Bradbury) writes:
> |I've just installed Microport Unix 5.3 Rel 2.1 on my Compaq 386.
> |I'm puzzled about the speed of the machine.  Microport UNIX 5.2
> This problem might be caused because the system is running a 8Mhz instead
> of 16Mhz.  Set SW-4 on the motherboard to off to force the system to boot
> at 16Mhz.

There is also a quirk in the DosMerge kernel under Unix 5.3 where a
background process called bdflush consumes (at least on my system) 93%
of the available CPU time when the machine would be otherwise idle. Running
a Dhrystone test here would time slice the CPU but it would still run
much slower do to that routine gobbling up the CPU time.
    -Mike
    {ihnp4, amdahl, rutgers}!meccts!cimcor!mike

garon@pedro.UUCP (Garon C. Yoakum (Power Crazy 386 Owner)) (01/21/88)

I also have noticed the problem with dhrystones on MicroPort V.3 Release 2.1

I suggest that we send mail to:  JOHN SULLY @ Microport Technical Services.