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