chau@caen.engin.umich.edu (Hin Fai Chau) (06/03/91)
This has long been a question in my mind. Can anyone please tell me whether I still need to install FASTOPEN and SMARTDRV or other disk cache programs such as HYPERDISK if I have already had a 32 K cache buffer in my disk controller card and another 64 K in my 386 processor? Does a software disk cache program actually create extra overheading if I have already got a hardware one? Thanks in advance. Hin-Fai Chau chau@caen.engin.umich.edu
pshuang@ATHENA.MIT.EDU (06/05/91)
In article <RL0+Y0.@engin.umich.edu> chau@caen.engin.umich.edu (Hin Fai Chau) writes: > This has long been a question in my mind. Can anyone please > tell me whether I still need to install FASTOPEN and SMARTDRV > or other disk cache programs such as HYPERDISK if I have > already had a 32 K cache buffer in my disk controller card > and another 64 K in my 386 processor? > Does a software disk cache program actually create extra > overheading if I have already got a hardware one? Here we go, my attempt to set a personal record for posting length: -------- cut here -------- (c) Copyleft 1991 by Ping Huang. * FASTOPEN is a very specific kind of caching program which keeps track of where DOS can find files (by maintaining a table of names with their locations on disk). It does not try to cache file contents. Therefore, for a small memory cost (i.e. 16Kb), it can be more efficient than a general kind of cache if your applications tend to open lots of different files all over the place. It can work well *WITH* general-purposes caches. Some people like FASTOPEN, others claim that it doesn't help speed much. It seems a matter of personal preference. * DISK CACHES: SMARTDRV and HYPERDISK are examples of general-purpose disk caches. These usually can make use of conventional, expanded, or extended memory in your computer to reduce the number of disk accesses by keeping copies of parts of the disk in memory. When something is read from or written to the disk, a copy of it is placed into the cache; the next time it is needed, if it is still in the cache, the computer never has to wait for the disk drive. Because RAM is so much faster than disk drives, often by 100,000 times (8ms versus 80ns), disk caches can improve the performance of applications which need to process disk files and aren't just doing mathematical/text manipulations in memory. General-purpose disk caches often don't understand the structure of your disk and "do their thing" at the sector level, i.e. they cache data as being sectors x, y, and z, and not as the file SOMEDATA.FIL. Some of the most sophisticated caches do understand a little bit about DOS file structures and will preferentially keep directory and FAT tables (index to where the files are on disk) in the cache over other data. The performance of disk caches depends greatly on what they do when the caches fill up. Typically, your computer will have something like twenty times more disk space than you have RAM. So you can easily see that it is quite possible (almost always, as a matter of fact) that the cache will fill up. When it does, the cache software has a couple of options. It could just stop caching, or it could take some of the old data that it cached a long time ago and discard it to make room to cache the new data. This is called the Least-Recently-Used algorithm, and how well it is implemented affects cache effectiveness greatly. Other factors which affect cache speed are how much memory you can give it, how fast the memory is (memory on expansion cards, for instance, is usually slower than memory installed on the motherboard), and how quick the software is at searching the cache for the data which your application requested, and whether it is intelligent enough to anticipate what your application wants and pre-load it (for example, if your application reads the first half of a file sequentially, it is quite likely to read the rest of the file, too). Another rather controversial way to speed up performance of a disk cache is to cache writes. What this means is that the software intecepts attempts to write to the disk by your application, and instead of both copying the data into the cache and writing it physically to the disk (and making the application wait), IT JUST PUTS IT INTO THE CACHE AND DOESN'T UPDATE THE DISK UNTIL SOME LATER TIME. This speeds things up because multiple writes to the same part of the disk can be eliminated and only one disk write would be necessary to write the last version, and because the cache can optimize the writing process if it can change the order of writes. For example, suppose your application software tries to write to data files which would ordinarily require that the disk seek to tracks 1,1000,2,999,3,998,4,997,etc in that order. This would be very slow because it takes a long time for the disk to seek long distances between tracks. However, with a non-write-through cache (there's a better term than this), the disk could seek to 1,2,3,4,... 997,998,999,1000 in order, and this would be much faster. Analogy: sorting the mail for your post-carrier in order of the houses in advance, so that he doesn't have to keep walking back and forth on the same block, but can just walk straight through once. The controversy is over the fact that *IF* your computer loses power or crashes before the data in the cache is written to the disk, then those changes are permanently lost. Cache effectiveness can be partially measured by a number known as the hit ratio. This number is simply the number of disk reads which could be satisfied from the cache divided by the number of attempted reads. Some caches claim a hit ratio greater than 90%, but your actual mileage will vary greatly depending on the kind of software you use. Databases tend to yield the lowest ratios, since they often randomly seek back and forth on the disk to fetch records and overflow the cache with data which is never accessed again. Sometimes, if the cache is large and the software search is not optimized for speed and the computer's hard disk is fast, it is slower to look things up in the cache than to simply read it from the disk in the first place since the overhead associated with the cache is so great in that situation. This, however, rarely happens. SMARTDRV is one of poorer disk caches around in terms of speed, but even it almost always improves disk access times greatly over not having any kind of cache software installed. What your disk controller probably has is not 32Kb of cache memory, but 32Kb of look-ahead buffer, unless it is a more expensive high- performance controller (usually for SCSI or ESDI disks). The difference is that cache memory usually requires some sort of microprocessor to implement (because decisions have to be made about whether to discard this part of the cache or that part and what to do about this and that...) and the extra hardware involved costs money. Look-ahead buffers can be implemented with cheap hardware, and basically when the computer asks for a particular sector, the disk controller loads the entire track on which the sector is found, plus maybe one or two more tracks right after it, depending on the particular disk and cache size. This works to speed things up because usually when the computer wants a sector, it *DOES* want the sectors after it, too. Buffers have a fairly high hit ratio (maybe 75%) and are worth the effort, but not as good as a disk cache. Using a buffer in conjunction with a true disk cache usually doesn't hurt, since the buffer adds only a little overhead. Using a true disk cache with a software disk cache causes some confusing results. It's difficult to ascertain if using *TWO* is detrimental to speed because there are two sources of overhead. One might think so, but on the other hand Byte magazine recently ran an article where the best speed came from combining a software and hardware cache; however, the additional speed is measured in just a few percent over the software alone, and only you can determine whether the additional cost is worth it. * CPU CACHE'S: CPU cache's are completely separate from disk caches, although they work on a similar idea. Modern microprocessors have become so fast that it is often too expensive to supply RAM which can keep up with them directly. For example, a 386-33 chip needs for RAM to respond to requests for data within less than 50 nanoseconds. The fastest commonly available memory components today run at 70-100ns. However, the faster the RAM, the more expensive it is. Currently, only RAM's designated as Static (versus the normal Dynamic RAMS, a.k.a. DRAM, and made by a slightly different process than Dynamics) can keep up, but they cost three to four times as much per megabyte. This would have added hundreds of dollars to the cost of my own 386 with four megabytes of memory, and make upgrading it to even memory an expensive endeavor. The cost of using slower RAM would have been decreased performance, because the CPU would have to wait for memory to supply it with data and to store calculated results, an effect summarized by the term wait states. This has only become an issue in the last five years or so, because while the clock speeds of the microprocessors have increased by a factor of ten or so, RAM has only become three to four times faster. There are other methods and tricks which can reduce this amount of slow-down due to the mismatching of CPU vs. RAM speed, but they are less popular and often less effective than caching. Motherboard manufacturers realized that if they placed a small (ergo not so expensive) cache of extremely high speed RAM (on the order of 20 nanoseconds) between the processor and main memory, they could use slower but cheaper RAM in their machines. As with disk caches, what determines the effectiveness of these caches are size (typically ranging from 64 to 256Kb, with the extremes being 8Kb and 1Mb) and the algorithm used to determine what cached data to throw away (usually not LRU but a simpler algorithm based on some mathematical property of the address being accessed). The term hit ratio is also used with RAM caches, and is usually claimed to be over 90%, although again your mileage may vary. Write-through versus non-write-through is also an issue here. Motherboard manufacturers can choose between different implementations of caches; they can use chips with built-in caches, such as the i486 family, use one of the predesigned chip-sets from Intel and other companies, or wire up their own custom version. There are various claims as to which one of these approaches is best, but with no conclusive results. What is conclusive is that caching does make a big difference... if your applications are compute-intensive and not disk-intensive, even if you're using the same kind of microprocessor running at the same clock rate, a system with a good cache may run as much as 25% faster than another one with a poor or no cache. -------- cut here -------- Recommendations: find and use a good disk cache (I recommend PC-Kwik and not SMARTDRV, unless you're often running Windows because the latter two can share use of the same memory), and load FASTOPEN if you are not already straining against the 640Kb barrier. Singing off, UNIX:/etc/ping instantiated (Ping Huang).
kooijman@duteca4.et.tudelft.nl (Richard Kooijman) (06/06/91)
pshuang@ATHENA.MIT.EDU writes: >(c) Copyleft 1991 by Ping Huang. > * FASTOPEN is a very specific kind of caching program which keeps track >of where DOS can find files (by maintaining a table of names with their >locations on disk). It does not try to cache file contents. Therefore, >for a small memory cost (i.e. 16Kb), it can be more efficient than a >general kind of cache if your applications tend to open lots of >different files all over the place. It can work well *WITH* >general-purposes caches. Some people like FASTOPEN, others claim that >it doesn't help speed much. It seems a matter of personal preference. Well, BYTE Mag. has done some tests on FASTOPEN and I have also done some tests myself. Conclusions of us both were that FASTOPEN only delivers 5% speed advantage. Only programs that do a lot of opening and closing of files (dBase ?) may benefit more than 5%. Richard. -- Richard Kooijman | (__) Delft University of Technology | (oo) ------------------------- Dept. Electrical Engineering | /-------\/ - | Don't have a Bart, man! | Section Computerarchitecture | / | || ------------------------- Neural Network Group | * ||----|| Room 10.04 | ^^ ^^ kooijman@duteca.et.tudelft.nl | The Simpsons' cow