Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!tut.cis.ohio-state.edu!ukma!cwjcc!neoucom!wtm
From: wtm@neoucom.UUCP (Bill Mayhew)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: (Disk) Cache problems...
Summary: Depends on how the application accesses the disk
Keywords: Cache
Message-ID: <1843@neoucom.UUCP>
Date: 26 Nov 89 16:22:42 GMT
References: <638@ariadne.csi.forth.GR>
Distribution: comp
Organization: Northeastern Ohio Universities College of Medicine
Lines: 26


	Most, perhaps all, disk caching programs buffer the BIOS
INT 13H disk interface.  Programs that directly access sectors will
escape the benefits of the cache.  Knowing Microsoft, it wouldn't
surprise me to find out they were doing such a thing in attempt to
enhance performance to access the headerfiles and libraries...  The
other thing one has to keep in mind is that the cache is of little
value when you don't read the same information more than once.  The
DOS caches I've seen don't do read-ahead caching; they only cache
sectors as they are read (that is not to say that read-ahead caching
can not be done in DOS; it is a trade-off between lengthened times
on short reads and increasing the likelyhood of a cache hit on a
sequential read).  All DOS caches actually slow down performance on
reads of previously unread sectors.

	Now, there are hardware boards that do read-ahead
trahsparently to DOS, such as the Mylex disk controller.  The Mylex
controller doesn't know about DOS' file system, so it doesn't do
file based read-aheads, but rather buffers an entire cylinder of
data at a time.  On an unfragmented disk, the performance
enhancement is quite noticable.  The Mylex board also can be
outfitted with several megabytes of RAM so that it can quickly
recall previously read sectors.

Bill
wtm@neoucom.edu