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 disclaimers
forrest@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