[comp.windows.ms] Performance degradation in 386 enhanced mode

a752@mindlink.UUCP (Bruce Dunn) (01/17/91)

     From recent responses, it is apparent that there is some confusion about
the problem which is being experienced.  The basic problem is as follows:

     On some machines, but not all, tasks running in 386 enhanced mode are much
slower than in standard mode.  This can be seen by using the computational
index from the Norton Utilities in both standard mode and 386 enhanced mode.
It can also be seen for some programs such as the Microsoft Flight simulator,
which become extremely sluggish in 386 enhanced mode but are ok in standard
mode.
     This problem has nothing to do with swap files - disk access is not
involved in demonstrations of the problem.  The problem has nothing directly to
do with memory size - the performance difference occurrs between two different
modes on the same machine with the same memory.
     There seems to be some correlation with the speed of machines - one report
has stated that the problem occurrs on 16 MHz machines but not on 20 MHz
machines.
     I have the problem on a 16 MHz 386 (not a 386 SX).  I wonder if the
problem is because my memory above 1 megabyte is not on the motherboard, but is
on a memory card on the bus which can only be accessed at bus speed.  My
hypothesis is that when run in standard mode, Windows runs mainly in the 1
megabyte of easily accessible memory on the motherboard, but when I ask for
enhanced mode much more use is made of the memory which can only be accessed
through the bus.       Would people who have the problem please mail me
information on whether their memory is all on the motherboard, or whether part
is accessible only through the bus.
     An alternate explanation is that 16 megahertz machines tend to be older
designs than 20 megahertz machines, and there may have been some subtle changes
in motherboard technology in the last couple of years which affect the relative
speeds of standard and enhanced modes.
    Once again, we are talking about computational speed in situations where
disks are not being accessed - disk caches and swapfiles are not involved.
--
Bruce Dunn   Vancouver, Canada    a752@mindlink.UUCP

a752@mindlink.UUCP (Bruce Dunn) (01/18/91)

> dkyoon@pollux.usc.edu writes:
> 
> 
> The performance degradation in 386 enhanced mode is the result of
> multitasking of windows applications even a DOS app is running with
> exclusive box checked.  In standard mode, if a dos app is
> activated, all other apps including windows apps are suspended.
> However, in enhanced mode, windows apps are always able to get a
> time slice of CPU.  You can easily verify this by doing file transfer
> using one of the windows comm program (like winqvt), and focus on the
> DOS app which is supposed to be run exclusively.  You will see, the
> file transfer's going on in background.
> 
> I would appreciate any comments on my observation, and pealse correct
> me if I am wrong.
> 
> --
> Dae-kyun Yoon
> dkyoon@usc.edu, ..!uunet!usc!dkyoon


     I agree that multitasking puts more of a load on the processor, but this
is not an answer to the specific question being asked as this performance
degradation does not happen on certain machines.  I would expect 386 enhanced
mode to be slightly slower because of overhead, but not much slower unless
something were operating in the background, which is not the case in the
problems being described.
--
Bruce Dunn   Vancouver, Canada    a752@mindlink.UUCP

dkyoon@pollux.usc.edu (Dae-Kyun Yoon) (01/19/91)

a752@mindlink.UUCP (Bruce Dunn) writes:

>     On some machines, but not all, tasks running in 386 enhanced mode are much
>slower than in standard mode.  This can be seen by using the computational
>index from the Norton Utilities in both standard mode and 386 enhanced mode.
>It can also be seen for some programs such as the Microsoft Flight simulator,
>which become extremely sluggish in 386 enhanced mode but are ok in standard
>mode.
>     This problem has nothing to do with swap files - disk access is not
>involved in demonstrations of the problem.  The problem has nothing directly to
>do with memory size - the performance difference occurrs between two different
>modes on the same machine with the same memory.
>     There seems to be some correlation with the speed of machines - one report
>has stated that the problem occurrs on 16 MHz machines but not on 20 MHz
>machines.

I agree that the performance degradation in 386 Enhaced mode has *almost*
nothing to do with swap file.  And it also has nothing to do with the
speed of the machine.  Of course, if the machine is faster, the performance
in 386enhanced mode is better than on the slower machine.  However
we are talking about the relative performace degradation between standard
mode and enhanced mode on the same 386(386sx) machine.

The performance degradation in 386 enhanced mode is the result of
multitasking of windows applications even a DOS app is running with
exclusive box checked.  In standard mode, if a dos app is 
activated, all other apps including windows apps are suspended.
However, in enhanced mode, windows apps are always able to get a
time slice of CPU.  You can easily verify this by doing file transfer
using one of the windows comm program (like winqvt), and focus on the
DOS app which is supposed to be run exclusively.  You will see, the
file transfer's going on in background.

I would appreciate any comments on my observation, and pealse correct
me if I am wrong.

-- 
Dae-kyun Yoon
dkyoon@usc.edu, ..!uunet!usc!dkyoon

6600wise@ucsbuxa.ucsb.edu (Mike Schmitt) (01/19/91)

In article <4491@mindlink.UUCP> a752@mindlink.UUCP (Bruce Dunn) writes:


>     From recent responses, it is apparent that there is some confusion about
>the problem which is being experienced.  The basic problem is as follows:

I have seen various posts about this; one possible check is this: I
have hDC MicroApps (or FirstApps, or whatever they're calling them
now).  Apparently, when Windows goes after the disk in any manner
(meaning an application program running in a virtual 86 window, or
Windows itself, or any Windows app), and some sound is being 
generated at the same time, Windows will suddenly get extremely
sluggish and will be so until you exit Windows and restart it.

This is a bug acknowledged by Microsoft; they have committed to
fixing it in release 3.1.

Hope that helps!

Mike
6600wise@ucsbuxa.ucsb.edu

mikew@charm.LCS.MIT.EDU (Michael B. Williams) (01/19/91)

In article <29402@usc>, dkyoon@pollux.usc.edu (Dae-Kyun Yoon) writes:
|> I agree that the performance degradation in 386 Enhaced mode has *almost*
|> nothing to do with swap file.  And it also has nothing to do with the
|> speed of the machine.  Of course, if the machine is faster, the performance
|> in 386enhanced mode is better than on the slower machine.  However
|> we are talking about the relative performace degradation between standard
|> mode and enhanced mode on the same 386(386sx) machine.
|> 
|> The performance degradation in 386 enhanced mode is the result of
|> multitasking of windows applications even a DOS app is running with
|> exclusive box checked.  In standard mode, if a dos app is 
|> activated, all other apps including windows apps are suspended.
|> However, in enhanced mode, windows apps are always able to get a
|> time slice of CPU.  You can easily verify this by doing file transfer
|> using one of the windows comm program (like winqvt), and focus on the
|> DOS app which is supposed to be run exclusively.  You will see, the
|> file transfer's going on in background.
|> 
|> I would appreciate any comments on my observation, and pealse correct
|> me if I am wrong.

Two points:
1)  The term ``performance degradation''  isn't really strong enough.  We're talking
about a SEVERE performance degredation (60% in my case).
2)  This severe performance degredation occurs on *some* similarly configured
machines, but not others, even when running the same programs in the same way.

Questions:
1)  It may be helpful to be able to isolate the problem to 16 MHz machines.  Does
anyone with a 20MHz machine have this problem?
2)  Bruce (your mail bounced):  I have 2MB on the motherboard, so I'll disable the
4MB RAM card I have and see if that could be the problem.

________________________________________________________________________
Michael B. Williams	      \ 1-2-3-4, KICK THE LAWSUITS OUT THE DOOR
MIT NE43-532 		       \ 5-6-7-8, INNOVATE DON'T LITIGATE
Laboratory for Computer Science \ 9-A-B-C, INTERFACES SHOULD BE FREE
545 Technology Square	         \ D-E-F-0, LOOK AND FEEL HAS GOT TO GO!
Cambridge, MA 02139		  --------------------------------------
(617) 253-5983   Internet: mikew@athena.mit.edu   CompuServe: 73667,3264

medici@dorm.rutgers.edu (Mark Medici) (01/19/91)

I know this may sound a little silly, but have you considered trying a
different keyboard?

What!?!  The keyboard?

Well, if I understand correctly, DOS systems built around the 286 and
386 use the keyboard controller chip to switch between real mode (the
only place you can run DOS) and protected mode (where Win3 in 386 mode
lives, and also required for HIMEM.SYS to operate).  Windows and/or
HIMEM.SYS tell the keyboard to reset the '386 (after setting-up the
system so it won't go through a normal reboot sequence) when any DOS
or BIOS calls are needed.  This happens infrequently in Windows
itself, but often when running a DOS window so that other Windows apps
get some processing time.  Even HIMEM.SYS steals some processing time
this way, as it manages XMS memory.

So, I'd suggest you try using a different manufacture of keyboard.
Ideally, an IBM ehanced keyboard would be the best test.

BTW, my IBM PS/2-80 (20MHz) reports the following with Norton's SI
version 4.5:

	Plain old DOS:	22.1
	HIMEM.SYS:	21.5
	Win3 + HIMEM:	21.0

-- 
-----------------------------------------------------------------------------
Mark Medici ** Systems Programmer III * Rutgers University Computing Services
medici@elbereth.rutgers.edu * medici@cancer.BITNET * !rutgers!elbereth!medici
My opinions are not necessarily my employers'. *Reality is context-sensitive.

billf@progress.COM (Bill Ferro) (01/19/91)

a752@mindlink.UUCP (Bruce Dunn) writes:

>     On some machines, but not all, tasks running in 386 enhanced mode are much
>slower than in standard mode.  This can be seen by using the computational
>index from the Norton Utilities in both standard mode and 386 enhanced mode.
>It can also be seen for some programs such as the Microsoft Flight simulator,
>which become extremely sluggish in 386 enhanced mode but are ok in standard
>mode.
>     This problem has nothing to do with swap files - disk access is not
>involved in demonstrations of the problem.  The problem has nothing directly to
>do with memory size - the performance difference occurrs between two different
>modes on the same machine with the same memory.
	[other stuff deleted]
>Bruce Dunn   Vancouver, Canada    a752@mindlink.UUCP

Bruce, the answer lies in the fact that the enhanced mode uses the virtual
8086 mode of the 386 chip.  I am familiar with protected mode on a 386 but
not so on the 286.  The virtual box created in enhanced mode causes a protection
fault on EVERY int instruction and port access.  The overhead involved in saving
the current task state in the TSS and switching to another task, executing the
instruction and returning to the original task is not minimal.
Programs like Norton's SI are not a very good indication of overall true speed (or
lack thereof) in a virtual mode environment.  I do agree though, that 386 enhanced 
mode is too slow.  Another speed problem is that fact that WINDOWS goes through
DOS to do file access -- windows is not really an operating system -:(

Now, can anyone explain to us why in 286 virtual mode (where only 1 can exist) is
faster than 386 virtual mode (many can exist)??????


--
Bill Ferro			UUCP: mit-eddie!progress!billf
Progress Software Corp.		Internet: billf@progress.com
5 Oak Park		  >>>>>>Opinions expressed herein are
Bedford, MA  01730	  >>>>>>are usually mine (sometimes

billf@progress.COM (Bill Ferro) (01/19/91)

a752@mindlink.UUCP (Bruce Dunn) writes:

>     On some machines, but not all, tasks running in 386 enhanced mode are much
>slower than in standard mode.  This can be seen by using the computational
>index from the Norton Utilities in both standard mode and 386 enhanced mode.
>It can also be seen for some programs such as the Microsoft Flight simulator,
>which become extremely sluggish in 386 enhanced mode but are ok in standard
>mode.
>     This problem has nothing to do with swap files - disk access is not
>involved in demonstrations of the problem.  The problem has nothing directly to
>do with memory size - the performance difference occurrs between two different
>modes on the same machine with the same memory.
	[other stuff deleted]
>Bruce Dunn   Vancouver, Canada    a752@mindlink.UUCP

Bruce, the answer lies in the fact that the enhanced mode uses the virtual
8086 mode of the 386 chip.  I am familiar with protected mode on a 386 but
not so on the 286.  The virtual box created in enhanced mode causes a protection
fault on EVERY int instruction and port access.  The overhead involved in saving
the current task state in the TSS and switching to another task, executing the
instruction and returning to the original task is not minimal.
Programs like Norton's SI are not a very good indication of overall true speed (or
lack thereof) in a virtual mode environment.  I do agree though, that 386 enhanced 
mode is too slow.  Another speed problem is that fact that WINDOWS goes through
DOS to do file access -- windows is not really an operating system -:(

Now, can anyone explain to us why in 286 virtual mode (where only 1 can exist) is
faster than 386 virtual mode (many can exist)??????



--
Bill Ferro			UUCP: mit-eddie!progress!billf
Progress Software Corp.		Internet: billf@progress.com
5 Oak Park		  >>>>>>Opinions expressed are usually
Bedford, MA  01730	  >>>>>>mine (sometimes they are on loan).

etxsral@california.ericsson.se (Lars Nilsson) (01/20/91)

In article <1991Jan19.033005.8733@mintaka.lcs.mit.edu> mikew@athena.mit.edu (Michael B. Williams) writes:
>In article <Jan.18.17.33.50.1991.29390@dorm.rutgers.edu>, medici@dorm.rutgers.edu (Mark Medici) writes:
>|> I know this may sound a little silly, but have you considered trying a
>|> different keyboard?
>|> 
>|> Well, if I understand correctly, DOS systems built around the 286 and
>|> 386 use the keyboard controller chip to switch between real mode (the
>|> only place you can run DOS) and protected mode (where Win3 in 386 mode
>|> lives, and also required for HIMEM.SYS to operate).  Windows and/or
>|> HIMEM.SYS tell the keyboard to reset the '386 (after setting-up the
>|> system so it won't go through a normal reboot sequence) when any DOS
>|> or BIOS calls are needed.
>|> So, I'd suggest you try using a different manufacture of keyboard.
[stuff deleted] 
>
>Now THIS is a solution that a like!  Anyone with easy access to an IBM
>keyboard want to give this a try?

I thought that the keyboard processor was placed on the motherboard.
And I also think that 80386 uses a different procedure to switch
between protected and real mode.
The solution to use the keyboard processor or some other dedicated
hardware to switch to real mode is because of that the 80286
can go to protected mode but not back again.
In 80386 they have a instruction to switch back ( I think ).

My thoughts are only from my memory :-)


--
Lars Nilsson        
Ericsson Telecom AB , Stockholm - Sweden
E-mail: etxsral@california.ericsson.se
Fidonet: Lars Nilsson @ 2:201/108.7

brandis@inf.ethz.ch (Marc Brandis) (01/21/91)

In article <4491@mindlink.UUCP> a752@mindlink.UUCP (Bruce Dunn) writes:
>     On some machines, but not all, tasks running in 386 enhanced mode are much
>slower than in standard mode.  This can be seen by using the computational
>index from the Norton Utilities in both standard mode and 386 enhanced mode.
>It can also be seen for some programs such as the Microsoft Flight simulator,
>which become extremely sluggish in 386 enhanced mode but are ok in standard
>mode.

When I get you right, the problem occurs only when you are running DOS programs
in a DOS window. If this is true, then I have an explanation for you.

>     There seems to be some correlation with the speed of machines - one report
>has stated that the problem occurrs on 16 MHz machines but not on 20 MHz
>machines.
>     I have the problem on a 16 MHz 386 (not a 386 SX).  I wonder if the
>problem is because my memory above 1 megabyte is not on the motherboard, but is
>on a memory card on the bus which can only be accessed at bus speed.  My
>hypothesis is that when run in standard mode, Windows runs mainly in the 1
>megabyte of easily accessible memory on the motherboard, but when I ask for
>enhanced mode much more use is made of the memory which can only be accessed
>through the bus. 

Windows does completely different things when running DOS programs under
standard mode or under enhanced mode. In standard mode, the CPU switches back
to real mode and lets the program run in real mode as if it were under plain
DOS. This is the same method that is used in OS/2 1.x for the DOS box. In
enhanced mode, a virtual machine in which to run the DOS program is created.

There are two important differences between a program running in real mode
and one running in a VM86. First, in real mode, only the first megabyte of
memory can be accessed, forcing your program into this first megabyte. In
VM86, the memory that your program sees can be located anywhere. It uses
virtual addresses, which are relocated to wherever the OS likes it. That is,
in standard mode, the DOS program goes always into the first megabyte, while
in enhanced mode it may not. On your machine this seems to make a big 
difference, as the memory above 1 Meg is much slower.

The other difference is that while in real mode, the CPU has full access to
all resources, in standard mode certain accesses cause traps to the underlying
OS (in this case, to Windows, which means a switch to another task running in
protected mode). If the program relies heavily on direct hardware accesses,
you may notice a performance degradation due to these traps.



Marc-Michael Brandis
Computer Systems Laboratory, ETH-Zentrum (Swiss Federal Institute of Technology)
CH-8092 Zurich, Switzerland
email: brandis@inf.ethz.ch

brandis@inf.ethz.ch (Marc Brandis) (01/21/91)

In article <1991Jan18.231328.24340@progress.com> billf@progress.COM (Bill Ferro) writes:
>Now, can anyone explain to us why in 286 virtual mode (where only 1 can exist) is
>faster than 386 virtual mode (many can exist)??????
>
There is no 286 virtual mode. The mode used to run DOS programs under Windows
in standard mode is real mode. Windows saves everything that may be destroyed
by the DOS session to disk before switching to this task. This is the reason
why the switch to such a task takes a rather long time. Note that the amount
of memory saved to disk is around 1 MB.


Marc-Michael Brandis
Computer Systems Laboratory, ETH-Zentrum (Swiss Federal Institute of Technology)
CH-8092 Zurich, Switzerland
email: brandis@inf.ethz.ch

brandis@inf.ethz.ch (Marc Brandis) (01/21/91)

In article <1991Jan19.033005.8733@mintaka.lcs.mit.edu> mikew@athena.mit.edu (Michael B. Williams) writes:
>|> Well, if I understand correctly, DOS systems built around the 286 and
>|> 386 use the keyboard controller chip to switch between real mode (the
>|> only place you can run DOS) and protected mode (where Win3 in 386 mode
>|> lives, and also required for HIMEM.SYS to operate).  

This is not true for the 386. On the 286, there is no way to switch from
protected mode to real mode except by resetting the CPU, which can be
achieved by using some circuitry in the keyboard controller. This takes a 
rather long time, so in this respect the comment is correct. It is also correct
that the required switching sequence depends on the keyboard and that there
are large differences in the execution times of them.

However, the 386 is a completely different story. First, there is a fast way
to switch back and forth between protected mode and real mode, which is 
controlled by one bit in CR0. All you have to do to switch is to set or reset
this bit (can be done in something like 15 cycles). Second, if Windows has to
switch to real mode for any reason and it is running on a 386, it uses this
method instead of the clumsy reset on the 286. This is even true if no 
enhanced mode is used (that is, in standard mode).

But the important point is that Windows in enhanced mode does very rarely
require to switch back to real mode, as DOS programs can be run in virtual
mode (which is a special kind of protected mode), so the whole story about
mode switching does not apply. There is only a task switch to switch to a
program in virtual mode, no processor mode switch as on the 286.


Marc-Michael Brandis
Computer Systems Laboratory, ETH-Zentrum (Swiss Federal Institute of Technology)
CH-8092 Zurich, Switzerland
email: brandis@inf.ethz.ch