Mail Archives: opendos/2000/11/24/17:59:36
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: <Matthias DOT Paul AT post DOT rwth-aachen DOT de>
Web : http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html
-------------------------------------------------------------------
- Raw text -