From: "Matthias Paul" Organization: Rechenzentrum RWTH Aachen To: opendos AT delorie DOT com Date: Fri, 24 Nov 2000 17:51:51 +0100 Subject: Re: Optimizing CONFIG.SYS... X-mailer: Pegasus Mail v3.22 Message-ID: <84A5E9D2033@reze-1.rz.rwth-aachen.de> Reply-To: opendos AT delorie DOT com On Thu, 23 Nov 2000 Patrick Moran wrote: > > VERIFY off > > DEVICEHIGH=NWCACHE ... /LEND=ON /DELAY=5000 /FLUSH=ON > [...] > I have not noticed that much increase in speed. Oh, there really is a drastic increase when you often write data. But you also need VERIFY to be disabled, because NWCACHE cannot delay any writes, when it is left on. > Also from many docs and messages from many users, it has been > found that using more than 2MB of either software cache or > hardware cache can actually slow the system down. Hm, when memory lending is disabled this can be true, because for various reasons applications may slow down in low memory scenarios (this depends on how much memory is left, of course). With memory lending enabled, I doubt that a large cache could slow down the system under normal conditions. Double buffering like when using large BUFFERS= settings in conjunction with NWCACHE may also slow down the system due to the unnecessary overhead involved. In some cases hardware caching might be that much faster that it makes no sense to have a software cache at the same time, so giving that memory to the application itself might cause some gain in speed. Theoretically, it would be possible that the cache strategies of multiple caches (including a combination of hardware and software cache) would interfere with each other (like waves that almost have the same frequency), and that this effect can be controlled by the size of the caches, but usually caching models (of any kind, not only disk caches) work in a staggered architecture at different abstraction levels and with large differences in speed, so the algorithms can hardly interfere. Just my ad-hoc opinion... > > > INSTALLHIGH=c:\drdos\nwcdex.exe /D:MTMIDE02 > > > > Usually it is not possible to loadhigh NWCDEX in CONFIG.SYS. > > A possible solution to still achieve this is to use my INSTCDEX > > utility available from my web-page (see footer). > > I have tried it both ways and seems to work, but it still used 7248 bytes > plus environment if done this way. I use it in the AUTOEXEC file > and use no conventional memory. 7 Kb with DPMS, 0,9 Kb with EMS (you need to force it to use EMS by telling it not to use DPMS, since otherwise DPMS takes preference). > NOTE: Notice that I use the LoadHigh before I load the CDROM extentions. > This will remove all of NWCDEX out of low memory. Otherwise I have > 7248 bytes plus whatever environment may be use low. You are lucky to have enough space left in UMB memory when you load NWCDEX in AUTOEXEC.BAT. It is normally very difficult to loadhigh NWCDEX at such a late state, because it needs much more memory during initialization. So, if you have trouble to load it high, try to load it as soon as possible. With the help of my INSTCDEX utility NWCDEX can also be loaded in CONFIG.SYS (where usually more UMB memory is still available). > DEVICE=C:\DRDOS\EMM386.EXE MULTI DPMI=ON FRAME=NONE /V I=B000-B7FF > /USE=F000-F6FF /R=AUTO DMA=64 > ^ > with USE F000-F9FF with the EMS FRAME set to: FRAME=E900!!!! Go figure! Yes, that's what I meant ;-) (I usually only find E800h to be working). MS-DOS EMM386 does not allow page frames above E000h, BTW... > FCBS=4,4 > ^ > I use the 4,4 because I experiment with QEMM. QEMM likes it. This > gives me an additional 4 files, which I do not need, but some old > programs still uses FCBS and if I play with CP/M I need it. Under DR-DOS, however, the system ignores the second argument. FILES and FCBS will be added and that count of handles minus 1 will be stored as FILES in SYSVARs (INT 21h/52h), while the internal FCBS setting is always 1 there (see Quarterdeck MFT report). Mind, that DR-DOS uses a combined pool of handles for both, file handles and system file control blocks, so this is just a matter of how to report this to the world, not a problem. > STACKS=0,0 Some systems (BIOSes???) and drivers actually require higher values or they crash. If it works, STACKS=0,0 is preferable, of course. Matthias ------------------------------------------------------------------- Matthias Paul, Ubierstrasse 28, D-50321 Bruehl, Germany eMail: Web : http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html -------------------------------------------------------------------