lane@dalcs.UUCP (John Wright/Dr. Pat Lane) (10/06/88)
What are the differences and what is the performance advantage in using
a disk cache program verses the DOS buffer system (controlled with BUFFERS=
in the CONFIG.SYS file). Assume for the sake of argument that 640K RAM is
available. I can see the following minor points:
- Caches are typically larger (64K up) than, say 20 buffers (10K of actual
buffer space), thus keeping more disk in RAM (faster access vs. less
available memory).
- Cache programs can usually be turned on and off or applied to specific
drives. Those that are resident programs (not installable drivers) can
in some cases be removed from memory.
- A cache program would have some memory overhead for the program; the code
for DOS buffers is there whether you take advantage of it or not.
- Some cache programs can put the cache in extended or expanded RAM which
would be a major memory advantage.
So what would be the difference between defining BUFFERS=128 vs. using a
64K cache? If you have a disk cache are you just as well to set BUFFERS=3
or less? Are some caches better than others? Are caches in extended or
expanded memory significantly slower than those in base memory or DOS buffers?
How would DOS 3.3's FASTOPEN factor into this?
Thanks for any opinions?
...JW
--
John Wright ///////////////// Phone: 902-424-3805 or 902-424-6527
Post: c/o Dr Pat Lane, Biology Dept, Dalhousie U, Halifax N.S., CANADA B3H-4H8
Cdn/Bitnet: lane@cs.dal.cdn Arpa: lane%dalcs.uucp@uunet.uu.net
Uucp: lane@dalcs.uucp or {uunet,watmath,utai,garfield}!dalcs!lane nelson@sun.soe.clarkson.edu (Russ Nelson) (10/08/88)
In article <3017@dalcs.UUCP> lane@dalcs.UUCP (John Wright/Dr. Pat Lane) writes:
So what would be the difference between defining BUFFERS=128 vs.
using a 64K cache?
BUFFERS are only used to satisfy requests for partial sectors.
If you have a disk cache are you just as well to set BUFFERS=3 or less?
No. I made some measurements of the time to do three chkdsks versus the
number of buffers. The curve goes roughly like this: Prior to five you
have an exponential decrease, and from five on up you have a linear increase.
.
.
. .
. . . . .
. .
1 2 3 4 5 6 7 8 9 10
So I would not advise you to set your buffers less than three. Five was
optimal, and six was near optimal. I cannot answer the rest of your
questions.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
To surrender is to remain in the hands of barbarians for the rest of my life.
To fight is to leave my bones exposed in the desert waste.news@steinmetz.ge.com (news) (10/08/88)
some of the mechanisms involved in dealing with them. It is unclear whether
the DOS buffer mechanism was ever intended to be a general purpose cache;
the original design was probabaly tuned for original PC's (small memory,
floppy disk) and never was enhanced significantly.
From: dixon@control.steinmetz (walt dixon)
Path: control!dixon
DOS uses its buffers to hold FAT and directory blocks. The only time a
buffer is used for read or write is when a partial block is being processed.
Internally DOS calls cached read/write routines when there is a possibility
of using its cache (eg directory search); otherwise it sends requests directly
to the device driver. The DOS buffer mechanism caches individual blocks.
DOS maintains the cache as a linked list and searches it linearly. The
caching code is actually some of the more brain-damaged code within DOS.
What does the previous explaination tell us? DOS absolutely must have one
buffer available to process partial read/write requests. (This one buffer
is actually allocated by IBMDOS initialization code so IBMBIO can process
CONFIG.SYS). Since DOS also uses buffers for FAT and directory block reads,
we probably want to have a minimum of one block available for each of these
blocks to avoid disk thrashing.
In reality you probably want several more buffers. FAT size, directory
size, and usage contribute to optimum number of buffers. Because the
buffer cache is searched linearly, allocating a large number of buffers
eventually hurts you. Note that the DOS buffer cache contributes nothing
to program i/o performance unless you are processing a lot of partial blocks.
How does a real cache help? It can improve performance substantially.
Using a better seach (ie hash)hcan speed up directory/fat access. If you
run applications that repeatedly access the same disk blocks, a real cache
program would eliminate some disk access. If you really like living
dangerously, a cache could defer writing some disk blocks (not recommended
for directory and fat blocks). A cache program can also do intelligent read
ahead (eg read a cluster at a time). The disk cache need nt be in the
lower 640K.
To summarize certain applications can benefit greatly from a cache. Unless
one really wants to muck around with DOS internals, one cannot prevent DOS
from searching its own cache for directory, fat, and partial read/write
requestsUsing a cache will effect the optimal value of buffers=; you
probably want a fairly small number of DOS buffers.
Walt Dixon {ARPA: dixon@ge-crd.com } }
{USMAIL: ge crd }
{ po box 8 }
{ schenectady, ny 12345 }
{PHONE: 518-387-5798 }
standard disclaimersforrest@ux1.lbl.gov (Jon Forrest) (10/09/88)
I don't know the answer but I can describe what I do. I use Lightning (a disk cache program) with no BUFFERS= statement in my CONFIG.SYS file. (I believe that there is a default number of buffers that are allocated if you don't give a BUFFERS= statement in CONFIG.SYS so you always have some buffers). Instead, I use a fairly large cache (80K). According to the statistics reported by Lightning, with the kind of work I do over 80% of my disk requests are found in the cache. Sometimes the percentage is even higher. I'm quite satisfied with this performance. By the way, the performance without Lightning turned on is noticably slower (and jerkier) than with it on. This is what you'd expect. Jon Forrest Lawrence Berkeley Lab., 486-4991 forrest@lbl.gov (internet) ucbvax!lbl-csam!ux1!forrest (uucp) FORREST@LBL (bitnet)
chris@lxn.UUCP (Christopher D. Orr) (10/14/88)
I can tell you a couple of good reasons to use caching:
(1) The cache that I use is one (1) Meg w/ my AST Rampage board on an
XT compatible. This gives me tremendous speed when doing
compiles and such (i.e. small->no disk access)
(2) The caching program that I use allows me to specify certain files
to always cache and certain files not to cache. This means that
I can set my editor/compiter up as always cache and let the
system decide what else should be cached. This is BETTER than a
ram disk since if I lose power, I won't lose my work (caches
always write to the disk if needed, but avoid those unnecessary writes).
Chris
--
Christopher D. Orr | US MAIL: Alcyone Inc.
UUCP: vu-vlsi!lehi3b15!lxn!chris | Lanark Building
or chris%lxn.uucp@rutgers.edu | Center Valley, PA 18034
| Voice: (215) 282-4525