jalbert@IRO.UMontreal.CA (Francois Jalbert) (06/21/91)
I successfully avoided upgrading from 3.3 to 4.0, but now I am faced with 5.0. When a friend of mine got 5.0, I was quite happy at the prospect of hearing about his experience with the new DOS. I learned about a new help facility. I already have one such stand-alone help program. I learned about some new utilities, I also have more such stand-alone utilities than I really care for. The same hold for intelligent command reentry. In fact, the more I thought about it, the more the only way to justify DOS 5.0 was because it leaves more conventional memory for the application programs. It's not that I am desperate for memory. 90% of my programs don't use anything near 640K. The last few remaining ones use my 3Mb RAM-disk for temporary files, so the slow-down is minimized. So I don't really need more than my usual 550K of free memory. Nevertheless, I thought that having (say) 600K free might be nice. Especially since DOS 5.0 seems reasonably priced. The Landmark (version 2.00) index for an ordinary 12 MHz 286 is 15.8; about 6.4 times the speed of an XT. But my friend found that as soon as he uses DOS=HIGH (I guess that's in the CONFIG.SYS, I'm not sure) to get more free conventional memory, the Landmark index falls down to a miserable 11.3, about 6 times the speed of an XT. I can understand a slow-down when accessing DOS buffers and doing some PATH search on a 286 with its lousy mode switching instruction. (although I heard some undocumented instruction is available to do it quickly) But I can't understand the slow-down would be permanent. Is DOS 5.0 using the tick interrupt to fiddle in the extended memory regularly. Strange! Perhaps the Landmark test is the one to blame. Perhaps it measures DOS' performance by asking DOS to do just such operations as internal buffer flushing, PATH scanning, etc. Operations requiring the mode switch. Anyway, I thought I'd ask anybody out there to try to find out if you do also experience on your 286 this awful slow-down. Now, that is reason enough for me never to touch DOS 5.0, but I can't think Microsoft would make such a mess of such a nice idea. It has to be the Landmark test. Anybody cares to reassure me? I am somewhat perplexed. Thanks! Franky
mosbrook@beach.csulb.edu (Brent Mosbrook) (06/22/91)
Have you tried changing your files= and buffers= statements? that sometimes can greatly alter the numbers given by norton. just a thought! -- +--------------------------------------+ | Brent Mosbrook KC6MWK | | mosbrook@beach.csulb.edu | +--------------------------------------+
gwni@troi.cc.rochester.edu (G. Wayne Nichols) (06/23/91)
My experience indicates that any use of HIMEM.SYS will dramatically slow down the Landmark rating, if not your actual system.
jin@spdcc.COM (Jerry Natowitz) (06/23/91)
In article <1991Jun23.034521.7819@galileo.cc.rochester.edu> gwni@troi.cc.rochester.edu (G. Wayne Nichols) writes: >My experience indicates that any use of HIMEM.SYS will dramatically >slow down the Landmark rating, if not your actual system. I have played around with various configurations and found that EMM386 seems to be the culprit - my apps are runjning in protected mode when I use it for upper memeory access. I don't even have to do any devicehighs or loadhighs, just having emm386 noems is enough. Maybe I'll try removing himem for laughs. -- Jerry Natowitz Guest user on: ARPA jin@ursa-major.spdcc.com UUCP {ima,harvard,rayssd,linus,m2c}!spdcc!jin
DSB100@psuvm.psu.edu (David Barr) (06/23/91)
In article <8043@spdcc.SPDCC.COM>, jin@spdcc.COM (Jerry Natowitz) says: >In article <1991Jun23.034521.7819@galileo.cc.rochester.edu> >gwni@troi.cc.rochester.edu (G. Wayne Nichols) writes: >>My experience indicates that any use of HIMEM.SYS will dramatically >>slow down the Landmark rating, if not your actual system. >I have played around with various configurations and found that EMM386 seems >to be the culprit - my apps are runjning in protected mode when I use it for >upper memeory access. I don't even have to do any devicehighs or loadhighs, >just having emm386 noems is enough. Maybe I'll try removing himem for laughs. Yes, if you think about it, it is obvious. EMS memory is _paged_ memory. That means when an application requests memory that is not in the 64K page frame, the page is swapped out, and another is brought in. This is a ludicrous system for managing memory, but for some stupid DOS programs, this is required, even on a 386. XMS is faster than EMS because it is a direct access system. If an application needs a memory value in XMS, it merely addresses it and reads it. I never use EMS unless I want to slow my system down. =) --Dave
liberato@dri.com (Jimmy Liberato) (06/24/91)
DSB100@psuvm.psu.edu (David Barr) writes: >In article <8043@spdcc.SPDCC.COM>, jin@spdcc.COM (Jerry Natowitz) says: >>In article <1991Jun23.034521.7819@galileo.cc.rochester.edu> >>gwni@troi.cc.rochester.edu (G. Wayne Nichols) writes: >>>My experience indicates that any use of HIMEM.SYS will dramatically >>>slow down the Landmark rating, if not your actual system. >>I have played around with various configurations and found that EMM386 seems >>to be the culprit - my apps are runjning in protected mode when I use it for >>upper memeory access. I don't even have to do any devicehighs or loadhighs, >>just having emm386 noems is enough. Maybe I'll try removing himem for laughs. >Yes, if you think about it, it is obvious. EMS memory is _paged_ memory. >That means when an application requests memory that is not in the 64K page >frame, the page is swapped out, and another is brought in. This is a >ludicrous system for managing memory, but for some stupid DOS programs, >this is required, even on a 386. XMS is faster than EMS because it is >a direct access system. If an application needs a memory value in XMS, >it merely addresses it and reads it. I never use EMS unless I want to >slow my system down. =) OK, but the original poster was talking about his 286 system, so EMM386 is not a problem. Further, why would paging a problem on a 386? The previous poster mentioned that he noticed a problem even with the EMS services turned off (EMM386 NOEMS). So, is it HIMEM.SYS that is the culprit? Is the MSDOS 5.0 EMM386 also an XMS driver ala QEMM or is HIMEM.SYS necessary. It would seem that HIMEM.SYS would be the only item common on both a 286 and a 386. -- Jimmy Liberato liberato@dri.com ...uunet!drivax!liberato "Truly great madness can not be achieved without significant intelligence." -Henrik Tikkanen
veit@du9ds3.uni-duisburg.de (Holger Veit) (06/24/91)
In <T8R4KTP@dri.com> liberato@dri.com (Jimmy Liberato) writes: >DSB100@psuvm.psu.edu (David Barr) writes: >>In article <8043@spdcc.SPDCC.COM>, jin@spdcc.COM (Jerry Natowitz) says: >>>In article <1991Jun23.034521.7819@galileo.cc.rochester.edu> >>>gwni@troi.cc.rochester.edu (G. Wayne Nichols) writes: >>>>My experience indicates that any use of HIMEM.SYS will dramatically >>>>slow down the Landmark rating, if not your actual system. >>>I have played around with various configurations and found that EMM386 seems >>>to be the culprit - my apps are runjning in protected mode when I use it for >>>upper memeory access. I don't even have to do any devicehighs or loadhighs, >>>just having emm386 noems is enough. Maybe I'll try removing himem for laughs. >>Yes, if you think about it, it is obvious. EMS memory is _paged_ memory. >>That means when an application requests memory that is not in the 64K page >>frame, the page is swapped out, and another is brought in. This is a >>ludicrous system for managing memory, but for some stupid DOS programs, >>this is required, even on a 386. XMS is faster than EMS because it is >>a direct access system. If an application needs a memory value in XMS, >>it merely addresses it and reads it. I never use EMS unless I want to >>slow my system down. =) >OK, but the original poster was talking about his 286 system, so EMM386 >is not a problem. Further, why would paging a problem on a 386? The previous >poster mentioned that he noticed a problem even with the EMS services turned off >(EMM386 NOEMS). >So, is it HIMEM.SYS that is the culprit? Is the MSDOS 5.0 EMM386 also an XMS >driver ala QEMM or is HIMEM.SYS necessary. It would seem that HIMEM.SYS would >be the only item common on both a 286 and a 386. >-- >Jimmy Liberato liberato@dri.com > ...uunet!drivax!liberato > "Truly great madness can not be achieved > without significant intelligence." -Henrik Tikkanen On a 286, the performance pig is probably himem.sys. The 286 has no direct operation to switch back from protected mode, which is necessary when accessing extended memory. It achieves it by two things: the undocumented operation LOADALL (to copy data between real and extended memory) and a "triple-bus-fault" to fall back int real mode from protected mode. Both operations are very expensive in time. If MSDOS 5.0 or FILE buffers are loaded behind the 1MB+64K barrier, the necessary (pseudo) paging operations may really slow down the system. (My opinion on this, could't checked this on my system, have a 386 only :-) Holger -- | | / Holger Veit | INTERNET: veit@du9ds3.uni-duisburg.de |__| / University of Duisburg | BITNET: veit%du9ds3.uni-duisburg.de@UNIDO | | / Fac. of Electr. Eng. | UUCP: ...!uunet!unido!unidui!hl351ge | |/ Dept. f. Dataprocessing |
mlord@bwdls58.bnr.ca (Mark Lord) (06/26/91)
In article <91174.112235DSB100@psuvm.psu.edu> DSB100@psuvm.psu.edu (David Barr) writes: <In article <8043@spdcc.SPDCC.COM>, jin@spdcc.COM (Jerry Natowitz) says: < <>In article <1991Jun23.034521.7819@galileo.cc.rochester.edu> <>gwni@troi.cc.rochester.edu (G. Wayne Nichols) writes: <>>My experience indicates that any use of HIMEM.SYS will dramatically <>>slow down the Landmark rating, if not your actual system. < <>I have played around with various configurations and found that EMM386 seems <>to be the culprit - my apps are runjning in protected mode when I use it for <>upper memeory access. I don't even have to do any devicehighs or loadhighs, <>just having emm386 noems is enough. Maybe I'll try removing himem for laughs. < <Yes, if you think about it, it is obvious. EMS memory is _paged_ memory. <That means when an application requests memory that is not in the 64K page <frame, the page is swapped out, and another is brought in. This is a <ludicrous system for managing memory, but for some stupid DOS programs, <this is required, even on a 386. XMS is faster than EMS because it is <a direct access system. If an application needs a memory value in XMS, <it merely addresses it and reads it. I never use EMS unless I want to <slow my system down. =) Excuse me while I roll in laughter! Dave does have a good point in that applications which use EMS may indeed run slower than those which do not, but not always.. XMS applications spend a lot of time copying data between the lower 1Mb and the extended memory above 1Mb. EMS applications merely ask the EMS manager to flip some control bits to remap 16K pages into the lower 1Mb. On a system with real EMS hardware, or on a 386 system with real remapping capability, this operation does not require that large amounts of memory be copied back and forth.. just the page bits get written to (notice that disk caching programs such as PC-KWIK recommend using EMS instead of XMS for the cache if you like to run your serial ports at high speeds). However, this point is irrelevant. Having EMS present on the system will normally not affect applications which do not use it!! In the case above, using EMM386 to "simulate" EMS is the culprit, not EMS or EMS applications. EMM386 places the 386/486 CPU into Virtual-8086 mode, which generally slows things down slightly, and specifically slows interrupts down more than slightly. This is more likely the real cause of the slight performance hit. -- MLORD@BNR.CA Ottawa, Ontario *** Personal views only *** begin 644 NOTSHARE.COM ; Free DOS 4.xx utility - use instead of SHARE.EXE MZQ.0@/P/=`J`_!9T!2[_+H``L/_/+HX&+`"T2<TAO@,!OX0`N1(`C,B.P/.DS <^K@A-<TAB1Z``(P&@@"ZA`"X(27-(?NZE@#-)P#-5 `` end
reisert@mast.enet.dec.com (Jim Reisert) (06/27/91)
In article <7153@bwdls58.bnr.ca>, mlord@bwdls58.bnr.ca (Mark Lord) writes... >EMM386 places the 386/486 CPU into Virtual-8086 mode, which generally slows >things down slightly, and specifically slows interrupts down more than >slightly. >This is more likely the real cause of the slight performance hit. Doesn't QEMM also put the processor into Virtual-8086 mode? I've found performance hits using coprocessor instructions with QEMM loaded (worse hits with EMM386), but no hit with no memory manager loaded. - Jim =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "The opinions expressed here in no way represent the views of Digital Equipment Corporation." James J. Reisert Internet: reisert@mast.enet.dec.com Digital Equipment Corp. UUCP: ...decwrl!mast.enet!reisert 146 Main Street Voice: 508-493-5747 Maynard, MA 01754 FAX: 508-493-0395