Mail Archives: opendos/1997/03/27/11:38:25
On Tue, 25 Mar 1997, Jude DaShiell wrote:
> There's something else I've noticed with floppy drives, even when
> they do work properly under opendos the transfer rate on file
> copying is very very slow. Don't know if that points at anything
> but there it is.
Well, this is definitely no bug, maybe a design flaw (which I think,
originally was caused from CP/M holdovers)...
I'll try to give several possible reasons for this, as far as I see
it (please correct me, if I'm wrong, since currently at system level
there are some pieces of the puzzle missing; we still don't have the
original sources to look at...). I will also give tips to speed up
file I/O:
- Reading floppies is equally fast as under MS-DOS/PC-DOS, only
writing is slower (ca. half the speed in the worst case without
NWCACHE). Some people were arguing that Novell DOS might do
better verification. Try to set "VERIFY off", which will even
speed up NWCACHE dramatically, since it needs "VERIFY off" to be
set for its buffered write.
- In opposite to MS-DOS/PC-DOS, the DR DOS family accesses drives
in a slightly different manner. This causes DR DOS to be slower
than MS-DOS/PC-DOS when changing drives, but will be faster
afterwards. You can see this with the updated PROMPT $p$g,
showing the current drive path.
- Floppy disk access can dramatically be slowed down by unproper
BUFFERS=/HIBUFFERS= settings in conjunction with the undocumented
DEBLOCK= directive... Personally, I don't experienced problems,
and therefore can use fastest DEBLOCK=FFFF (the segment address,
where to stop single sector deblocking instead of multi sector
access) on my systems. DEBLOCK=FFFF (which actually means:
multi-sector access over the full address space 1MB+64KB) is the
default for latest Novell DOS 7 systems, but has been A000
(the 640KB barrier, where conventional memory stops) before.
Some people running into compatibility problems with SCSI
controllers, improper support for VDS (virtual DMA specification),
or some older PS/2 machines might need to reduce to DEBLOCK=A000,
which normally is the start address of paged memory, or even to
DEBLOCK=0000, causing an serious impact of performance, since
this forces the kernel to route all file I/O through a single
sector deblocking buffer. (In some respect, MS-DOS' sometimes
undocumented MULTITRACK=ON/OFF directive is related to DEBLOCK.
Under Multiuser DOS, you can select seperate deblocking mechanisms
for each, hard disk I/O and floppy I/O, under Novell DOS/OpenDOS
it appears to me, that it can only be set globally.)
My systems work best with:
CONFIG.SYS:
INSTALL=EMM386 ...
INSTALL=DPMS or INSTALLHIGH=CLOAKING
...
DOS=HIGH,UMB
REM Without a cache like NWCACHE, you should at least
REM use BUFFERS=/HIBUFFERS=30, here...
REM BUFFERS=4 was the same in this configuration...
HIBUFFERS=4
DEBLOCK=FFFF
REM This one only prophylactically for Windows...
REM Most systems run fine with STACKS=0,0
STACKS=9,256
FASTOPEN=0
REM Without using QEMM tools in AUTOEXEC.BAT, you should
REM set them to FILES=60/80, FCBS=4,4, here...
REM Reduced to minimal values for MS Windows 3.1x to run...
REM Otherwise, Windows would report 'Unknown MS-DOS version!',
REM since it does not expect FILES=/FBCS= to be located in
REM UMBs (MS-DOS cannot do this).
FILES=8
FCBS=0,0
REM Note, that internally FILES and FCBS are handled in a
REM similar manner (MEM reports them both as HANDLES=).
...
DEVICEHIGH=NWCACHE ... /DELAY=5000 /FLUSH=OFF
AUTOEXEC.BAT:
REM Using QEMM 7.50+ FILES.COM and FCBS.COM to load them high...
REM You shouldn't do that in CONFIG.SYS, since it won't work
REM there as you would expect at the first glance!!!
LH ...\FILES.COM 80
LH ...\FCBS.COM 4,4
With DOS=HIGH,... the BUFFERS are put into the HMA, as with
HIBUFFERS=. Note, that IBMBIO.COM actually parses the second
parameter ss for look-ahead-buffers in HIBUFFERS/BUFFERS=nn,ss
which is undocumented. However, I'm somewhat curious about that,
since higher values for look-ahead-buffers, which should speed
up floppy access, have no visible memory impact on my systems,
but that may depend on configuration. (I imagine, the look-ahead-
buffers correlate with the deblocking buffer in Multiuser DOS,
which is configurable to values other than 1.)
I hope, this could help a little. I was interested to hear your
results...
Matthias
------------------------------------------------------------------
Matthias Paul ! My eMail address has changed. For some time !
Ubierstrasse 28 ! mails to former <MPaul AT ibh DOT rwth-aachen DOT de> !
D-50321 BRUEHL ! will be forwarded to the new address. !
eMail: <Matthias DOT Paul AT post DOT rwth-aachen DOT de>
WWW : URL: http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html
------------------------------------------------------------------
- Raw text -