From: "Matthias Paul" Organization: IBH, RWTH-Aachen To: opendos AT delorie DOT com Date: Thu, 27 Mar 1997 17:32:47 GMT+0100 Subject: Re: floppy disks Reply-to: Matthias DOT Paul AT post DOT rwth-aachen DOT de Message-ID: <48A06C54C2@ibh.rwth-aachen.de> 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 ! D-50321 BRUEHL ! will be forwarded to the new address. ! eMail: WWW : URL: http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html ------------------------------------------------------------------