Mail Archives: opendos/2000/05/08/13:58:41
On 30 Apr 00 Joseph Morris wrote:
> How can I improve the speed of disk read operations in DRDOS,
> specifically long file reads and searches?
A few more things to try:
- VERIFY OFF will dramatically speed up NWCACHE, as with VERIFY ON
NWCACHE cannot delay any writes.
- Using FILES and FCBS to leave them in conventional memory instead of
using their HI- or - HIGH variants may on some systems speed up
things.
- Don t use deep directory structures for the files that you access
frequently and reduce the amount of files in a directory. Large
directories will dramatically slow down things.
- Increase the BUFFERS or HIBUFFERS directive to the maximum that
fits into the HMA with the other HMA drivers in there.
- In contrast to what I usually recommend, use FASTOPEN=512 or
higher. Fortunately, FASTOPEN uses a very efficient hash
mechanism under DR-DOS and therefore each entry costs only 2
bytes, so FASTOPEN=512 costs 1 KB, while under MS-DOS it would
consum somewhat in the region of 15 Kb..30 Kb. Also, due
to the completely different implementation under DR-DOS, FASTOPEN
appears to be more (or fully???) stable on DR-DOS, while using it
imposes a serious risk to damage your file system on MS-DOS
(because under MS-DOS, the entries may not always get updated
when physically moving files by disk defragmenters - always
reboot your system when they have finished!).
- Try DEBLOCK=FFFF in CONFIG.SYS. This also speeds up things
(if it is not the default already - which is detected on
startup), but it may make your system unstable if you are
using old SCSI or ESDI drivers for harddisks (pre Virtual
DMA Specification (VDS) 1.0). However, I have yet to see
a system where it actually caused problems.
I don t think that cooling your harddisks or the like is a good
idea to speed up things. If they get so hot, that they don t
work properly any more, you should forget about any serious work
to do on such a machine. Server harddisk or harddisks in mounting
racks may need cooling, but hot to make them faster, but to
not exceed their working specifications...
Speaking of such, if harddisks are not properly fixed in the case
they may slow down because they need more time to find the
tracks on the disks because of the vibrations of the whole disk
on track seeking. However, running HDDs not in flat position or
90 degrees to the ground level, or not properly fixed in the case,
or put on rubber distancers to reduce noise is a very bad idea
to try when you want to have a reliable and long-lasting disk.
This may dramatically reduce the life-cycle from many years to
a a few months or weeks (worst case).
> I have 96MB of memory, so a larger disk cache was the first obvious step.
As already mentioned, a RAMdisks is also a good solution. One of the
best and smallest RMdisk drivers I know is Ciriaco Garcia de Celis
TDSK which you can find for example in the FreeDOS distribution.
In negotiation with Ciri I have been working on a new issue
of this driver properly handling up to 64 MB disk size now,
you can have a stable beta issue directly from me, if you want.
> Having seen how fluidly the my program runs when compiled for Linux,
> or even the DOS version run in Windows 95, I'm a bit concerned
> about how slow it is running under DRDOS.
Have you tried it under pure MS-DOS, or from within the GUI?
(The Windows GUI loads VCache, which - sometimes - is actually
a big improvement compared to DOS-only caches, because of
different assumptions it can rely on under the GUI, more room
for a caching algorithms and a bigger cache size).
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 -