bressler@iftccu.ca.boeing.com (Rick Bressler) (06/27/90)
I went home and read my QEMM manual (V5.0) and no page 22 it claims that the 386 is placed into virtual 8088 mode whenever expanded memory is in use or constantly if mapped ram or rom are used. (Mapped RAM is usually what loadhi uses). This pretty much means that if you are using QEMM your machine is going to be in v 8086 mode! Again I would like to stress, this mode is required (as far as I know) to do some of the things that QEMM does, it is not a problem with QEMM. Rather it is a problem with the overhead of the 80386 in dealing with interrupts in v 8086 mode. I wonder... does the 486 handle this any better??? Am I full of hot air? -Rick-
mcdonald@aries.scs.uiuc.edu (Doug McDonald) (06/27/90)
In article <1470012@iftccu.ca.boeing.com> bressler@iftccu.ca.boeing.com (Rick Bressler) writes: >I went home and read my QEMM manual (V5.0) and no page 22 it claims that the >386 is placed into virtual 8088 mode whenever expanded memory is in use or >constantly if mapped ram or rom are used. (Mapped RAM is usually what loadhi >uses). This pretty much means that if you are using QEMM your machine is >going to be in v 8086 mode! > >Again I would like to stress, this mode is required (as far as I know) to do >some of the things that QEMM does, it is not a problem with QEMM. Rather it >is a problem with the overhead of the 80386 in dealing with interrupts in >v 8086 mode. I wonder... does the 486 handle this any better??? > >Am I full of hot air? > You are full of warm air or slightly distended with hot air. If I read the book on the 386 I have - "Programming the 80386" by John H. Crawford amd PAtrick P. Gelsinger, the 80386 handles interrupts in the same time in real 8086 mode or virtual 8086 mode. What takes longer is interrupts in 386 or 386 protected mode. It appears that, as best I can, there will be no long delays so long as you go into virtual 8086 mode and stay there. But there WILL be long delays if QEMM has to change around the paging registers, as it must to support different tasks or to support simulated expanded memory, for to do this it must go into and out of protected mode, which is indeed slow. What WOULD take longer is if some of the protections available in virtaul 8086 mode like trapping hardware interrupts or IO instructions actually occur. This will indeed cause a very long delay. QEMM probably does not do this sort of stuff, as it almost certainly just lets the BIOS and regular IO instruction sdo their thing. Some virtual 8086 managers uner, for example, Unix, probably DO do this trapping, and WILL show a large slowdown. It depends on the IOPL it runs the virtual 8086 at. Complicated. Doug McDonald
bressler@iftccu.ca.boeing.com (Rick Bressler) (06/28/90)
Actually, if not useing the mapping features, QEMM has an auto mode that will switch out of protected mode when not actually using expanded memory. (at least according to the manual). It seems that there might be enough interest to reprint (by permission) a note from John Lefor, University of Rochester, Dept of E. Engineering The following states more clearly than I could some of the issues. -------------------------------------------------------------------------- When QEMM (or any other '386 EMM) goes into V86 mode various things have to happen. First why do they go into V86 mode? The answer is that in order to provide memory at addresses outside of where real memory exists QEMM must map memory. In order to map memory the '386 must be in protected mode or V86 mode (actually V86 mode runs in protected mode but the task is labelled a V86 task). Now in V86 mode you have all the overhead of protected mode (most instructions take loner to execute since they have to be checked for protection exceptions). In addition there is a need to trap (at least) all interrupt calls and all DMA activity. The interrupts are trapped and examined. The trap happen in protected mode and then the interrupt must be handed down to the V86 task. The interrupts must be trapped because in protected mode interrupts are processed by the IDT while in real mode the interrupts are processed by interrupt vectors in low memory. Now DMA -- Becase memory is being mapped all memory move operations on the CPU have their address translated by a set of page translation tables. Unfortunately DMA operations do not have their addresses processed by these tables so all DMA operations must be trapped and the source/destination and addresses must be examined. If the memory being moved is not physically at the same address as the program thinks it is (because the memory is mapped) then the DMA trap must translate the addresses to reflect the mapped address. If the length of an operation causes the DMA operation to span more than on contiguous bit of mapped memory then not only must the I/O address be changed but it must be broken into several pieces to allow the translated addresses to correspond to where it should be placed. Note that there are even bigger problems with bus master devices and I/O to translated memory. To address this IBM has announed another specification to let developers of bus master cards build drivers which can have their addresses translated by programs that map memory. I hope this helps you understand the whys of 386 EMMs and their performance problems. The magnitude of the impact on performance will be in part based on the silicon design of the chip and in part based on the methods chosen by the EMM writer on how to deal with these problems.
mms00786@uxa.cso.uiuc.edu (06/29/90)
Umm, since the address translation unit is built into the 80386 as far as I know, what, then, is the advantage of DMA? Obviously, since the 80386's translation unit is tied up, the 'rest' of the 80386 cannot be doing anything even if all it needs is in the cache /* assuming various things about the cache */. Now, obviously, memory protection schemes and DMA have been around for a long time, so anyone care to mention how a VAX or IBM or whatever handles this type of situation? Milan .
ppa@hpldola.HP.COM (Paul Austgen) (06/29/90)
> / hpldola:comp.sys.ibm.pc / shim@zip.eecs.umich.edu (Sam Shim) / 11:51 am Jun 26, 1990 / > In article <11250139@hpldola.HP.COM> ppa@hpldola.HP.COM (Paul Austgen) writes: > >I just started using Desqview 2.2 on my 386, and I noticed that > >the screen display is pretty slow. When I use MORE and also do > >directory listings, it seems to paint and stop, and continue on > >again. This surprised me, since I gave the foreground 99 tics, > >and the background only 3 tics. > > First, you should not set the forground to 99 ticks and the backgroud > 3 tics since you are multitasking with a ratio of about 5 seconds to > 1/6 of a second. I hope you were doing that only for testing. I keep > my ratio at 1:1. I am doing this because I am not really that interested in multi-tasking. I am interested primarily in the performance of the foreground task. In this case, I am running Microsoft Word, and the mouse sprite seems a little jerky with the recommended ratio of 9 to 3. My main motivation for using DV was to keep alive my communications program to keep a telnet connection to my Unix cluster server. Even this 99 to 3 ratio seems to keep the connection alive just fine. > Screen updates are fast and smooth, both for the > foreground app and the background apps. This might help. If not, turn off > direct writes to screen if you running programs that do not do direct > writes. Turn of virtualization when you don't need/want it. Turning off virtualization cured the problem. Excellent point. > Make sure > you are using the proper graphics driver. I'm not sure what you mean here. I believe that DV selected it from its bag of tricks during installation. > Take out ansi if you are using > it. > Why? I have ansi.sys installed in the main memory (pre-DV invocation). For the dos window (BigDos), I use dvansi, since ansi doesn't seem to survive through to the DV windows. > Hopefully one of these will fix it. > Thank you for your reply. The virtualization seems to have done the trick. > > ----------------------------------------------------------------------------- > | Sam Shim | Bart: Your succumbing to | > | EECS Departmental Computing Organization | mob mentality, Dad. | > | University of Michigan | Homer: Don't be ridiculous, son. | > | | I'm hopping on the | > | internet: shim@zip.eecs.umich.edu | bandwagon! Get with | > | Compuserve: 72371,1277 | the winning team! | > ----------------------------------------------------------------------------- > ----------
ganzer@cod.NOSC.MIL (Mark T. Ganzer) (06/30/90)
In article <11250141@hpldola.HP.COM> ppa@hpldola.HP.COM (Paul Austgen) writes: > >Why? I have ansi.sys installed in the main memory (pre-DV >invocation). For the dos window (BigDos), I use dvansi, since >ansi doesn't seem to survive through to the DV windows. > The Desqview docs mention that it will not use ansi.sys if loaded before Desqview, and that ansi needs to be loaded in each window in which it is used. BTW, PC Magazine' ansi.com also works well in a Desqview window. I mention this because I read complaints about dvansi. -- Mark T. Ganzer Naval Ocean Systems Center, San Diego UUCP: {bonnie,sdcsvax,gould9,hp-sdd} - !nosc!ganzer {apl-uw,ncr-sd,bang,crash } / Internet: ganzer@nosc.mil Compu$erve: 73617,442
simon@hpspwr.enet.dec.com (Curiosier and curiosier...) (07/01/90)
In article <11250141@hpldola.HP.COM>, ppa@hpldola.HP.COM (Paul Austgen) writes... >> / hpldola:comp.sys.ibm.pc / shim@zip.eecs.umich.edu (Sam Shim) / 11:51 am Jun 26, 1990 / >> First, you should not set the forground to 99 ticks and the backgroud >> 3 tics since you are multitasking with a ratio of about 5 seconds to >> 1/6 of a second. I hope you were doing that only for testing. I keep >> my ratio at 1:1. > > I am doing this because I am not really that interested in >multi-tasking. I am interested primarily in the performance of >the foreground task. In this case, I am running Microsoft Word, >and the mouse sprite seems a little jerky with the recommended >ratio of 9 to 3. If you do not need multitasking, you may want to set "Runs in the background" option to NO for each program that you have in your list (see Advanced Options in Change/Add Program). In this case the application that you open but do not use (e.g., you do not need Word Perfect runnign in the background) will freeze and will not affect the application that you are using. The comm programs are exceptions, you do want background file downloading. For them use Rearrange/Freeze option of the main menu when you do not need up/downloading. --------- Leo Simon simon@pwrvax.enet.dec.com Who is not liberal when young, does not have a heart. Who is not conservative when old, does not have a brain. -- W. Churchill
simon@hpspwr.enet.dec.com (Curiosier and curiosier...) (07/01/90)
In article <1984@cod.NOSC.MIL>, ganzer@cod.NOSC.MIL (Mark T. Ganzer) writes... >In article <11250141@hpldola.HP.COM> ppa@hpldola.HP.COM (Paul Austgen) writes: >> >>Why? I have ansi.sys installed in the main memory (pre-DV >>invocation). For the dos window (BigDos), I use dvansi, since >>ansi doesn't seem to survive through to the DV windows. >> >The Desqview docs mention that it will not use ansi.sys if loaded before >Desqview, and that ansi needs to be loaded in each window in which it is >used. Using ansi.sys I had many problems with a mouse -- the mouse cursor left "footprints" on the screen while using Norton Commander under DESQview. I removed ansi and replaced it with dvansi.com loaded through autoexec.bat as a TSR (QEMM threw it into high memory). No more problems with video. For reference: I have a Paradise VGA with the original NEC Multisync monitor, DESQview 2.25, QEMM 5.0. --------- Leo Simon simon@pwrvax.enet.dec.com Who is not liberal when young, does not have a heart. Who is not conservative when old, does not have a brain. -- W. Churchill
ppa@hpldola.HP.COM (Paul Austgen) (07/03/90)
> > I am doing this because I am not really that interested in > >multi-tasking. I am interested primarily in the performance of > >the foreground task. In this case, I am running Microsoft Word, > >and the mouse sprite seems a little jerky with the recommended > >ratio of 9 to 3. > > If you do not need multitasking, you may want to set "Runs in the > background" option to NO for each program that you have in your list > (see Advanced Options in Change/Add Program). In this case the > application that you open but do not use (e.g., you do not need Word > Perfect runnign in the background) will freeze and will not affect the > application that you are using. > I also seem to remember reading in the manual that Desqview will not spend multitasking time on a program that is waiting for keyboard input only. If this is the case, then it might be better to allow them to run. That way, if they do have something to do, they can, but they normally wouldn't, such as my Microsoft Word. > The comm programs are exceptions, you do want background file > downloading. For them use Rearrange/Freeze option of the main menu when > you do not need up/downloading. > This has not been my experience. This particular program is the public domain terminal emulator from NCSA. It is controlling an "ethernet" card. Programs like "Switch-It", that swap out tasks, will cause the connection to the cluster server (a Unix workstation in this case) to be lost. I believe that there is either a keep-alive response that is required periodically, or else switching out the task drops some line on the interface card. If you are running a downloading program only, things may be different. Thanks for your reply. > > --------- > Leo Simon simon@pwrvax.enet.dec.com > > Who is not liberal when young, does not have a heart. > Who is not conservative when old, does not have a brain. > > -- W. Churchill > ----------
reisert@ricks.enet.dec.com (Jim Reisert) (07/05/90)
In article <11250143@hpldola.HP.COM>, ppa@hpldola.HP.COM (Paul Austgen) writes... > >I also seem to remember reading in the manual that Desqview will >not spend multitasking time on a program that is waiting for >keyboard input only. This isn't strictly true, I think. If a program is continually polling the keyboard, it will still chew up CPU time until its slot has expired. There is a memory-resident program called TAME, written by David G. Thomas and Powersoft, that is supposed to prematurely vacate a program's slot if there is no keyboard input. I've found it very effective in making my communications windows run more smoothly under DESQview. The program can be found on SIMTEL20 as: PD1:<MSDOS.DESQVIEW>TAME230.ZIP So in your case, even if the program is just waiting for input, it's better to not allow it to run in the background, unless you have TAME. jim =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "The opinions expressed here in no way represent the views of Digital Equipment Corporation." James J. Reisert Internet: reisert@ricks.enet.dec.com Digital Equipment Corp. UUCP: ...decwrl!ricks.enet!reisert 77 Reed Road Hudson, MA 01749-2895
jbreeden@netcom.UUCP (John Breeden) (07/05/90)
In article <11250143@hpldola.HP.COM> ppa@hpldola.HP.COM (Paul Austgen) writes: >This has not been my experience. This particular program is the >public domain terminal emulator from NCSA. It is controlling an >"ethernet" card. Programs like "Switch-It", that swap out tasks, >will cause the connection to the cluster server (a Unix >workstation in this case) to be lost. I believe that there is >either a keep-alive response that is required periodically, or >else switching out the task drops some line on the interface >card. Acually, NCSA (and all IPs) use a protocol port that the transport layer talks to. When DesQ switches it's time slice away from NCSA, the port disappears and the sender (your workstation) times out. It's not a problem with the ethernet card, there's just no method to tell the sender that the port is really there (a number of solutions have been proposed). The problem is how NCSA handles a multitasker (or multitasker handles NCSA).
ralf@b.gp.cs.cmu.edu (Ralf Brown) (07/05/90)
In article <13085@shlump.nac.dec.com> reisert@ricks.enet.dec.com (Jim Reisert) writes: }In article <11250143@hpldola.HP.COM>, ppa@hpldola.HP.COM (Paul Austgen) writes... }>I also seem to remember reading in the manual that Desqview will }>not spend multitasking time on a program that is waiting for }>keyboard input only. } }This isn't strictly true, I think. If a program is continually polling the }keyboard, it will still chew up CPU time until its slot has expired. There Depends on how it checks the keyboard. If it asks for the next keystroke, then DV puts it to sleep until one becomes available. If it just asks whether a keystroke is available in a loop, then it will indeed use up its entire timeslice. -- {backbone}!cs.cmu.edu!ralf ARPA: RALF@CS.CMU.EDU FIDO: Ralf Brown 1:129/3.1 BITnet: RALF%CS.CMU.EDU@CMUCCVMA AT&Tnet: (412)268-3053 (school) FAX: ask _How_to_Prove_It_ by Dana Angluin 23. proof by semantic shift: some standard but inconvenient definitions are changed for the statement of the result.
dhinds@portia.Stanford.EDU (David Hinds) (07/07/90)
In article <1470013@iftccu.ca.boeing.com> bressler@iftccu.ca.boeing.com (Rick Bressler) writes: > >Now in V86 mode you have all the overhead of protected mode >(most instructions take loner to execute since they have to >be checked for protection exceptions). In addition there is a need >to trap (at least) all interrupt calls and all DMA activity. > Actually, 386 instructions do not take longer to execute in protected mode, apart from the interrupt and i/o instructions that get trapped. All the 386's protection hardware is active all the time, even in real mode. For example, the segment translation hardware is active in real mode, but the segment descriptors are all initialized to look like normal 8088-style segments. You can get protection violations easily enough - use a 32-bit address mode with an offset of >64k in real mode, and you exceed the segment limit. Paging can slow things down, but not because anything takes longer to execute, just because address translation causes delays when the page table entry cache misses. -David Hinds dhinds@Popserver.stanford.edu