david@doe.utoronto.ca (David Megginson) (10/27/90)
Both of my hard drives, the ICD F.A.S.T. 85 and the Megafile 30, have finally learned to live together in peace, harmony and sibdom (brother/sisterhood). Now, how should I set up caching for the best effect under TOS 1.4? I have turned off write caching in the ICDBOOT driver (it scares the dung out of me), but I have to choose among using only Atari's CACHEnnn.PRG (which is _very_ fast), ICDBOOT's built-in read caching, or some combination of the two. Any suggestions? Is CACHEnnn.PRG safe to use with ICDBOOT, or does it need AHDI? This question is probably of enough general interest to warrant replies directly to the net. Thanks. David Megginson -- //////////////////////////////////////////////////////////////////////// / David Megginson david@doe.utoronto.ca / / Centre for Medieval Studies meggin@vm.epas.utoronto.ca / ////////////////////////////////////////////////////////////////////////
GERLOFF@tubvm.cs.tu-berlin.de (Olaf Gerloff) (10/29/90)
In article <1990Oct27.162723.2834@doe.utoronto.ca>, david@doe.utoronto.ca (David Megginson) says: > >Now, how should I set up caching for the best effect under TOS 1.4? >I have turned off write caching in the ICDBOOT driver (it scares >the dung out of me), but I have to choose among using only >Atari's CACHEnnn.PRG (which is _very_ fast), ICDBOOT's built-in >read caching, or some combination of the two. Any suggestions? Is >CACHEnnn.PRG safe to use with ICDBOOT, or does it need AHDI? > Hello David! CACHEnnn.PRG from Atari increases the number of disk-buffers which will be used by GEMDOS to cache the FAT- and DATA-sectors (including the directory- sectors). I don't know the ICD-driver, but I think it will cache the HD-sectors internally, so if you use CACHEnnn.PRG and the cache in the ICD-driver you wast only memory. The search-algorithm for cached-sectors is very good in TOS 1.4, so I prefered it. Greetings, Olaf
csbrod@medusa.informatik.uni-erlangen.de (Claus Brod ) (10/29/90)
david@doe.utoronto.ca (David Megginson) writes: >Now, how should I set up caching for the best effect under TOS 1.4? >I have turned off write caching in the ICDBOOT driver (it scares >the dung out of me), but I have to choose among using only >Atari's CACHEnnn.PRG (which is _very_ fast), ICDBOOT's built-in >read caching, or some combination of the two. Any suggestions? Is >CACHEnnn.PRG safe to use with ICDBOOT, or does it need AHDI? You can combine all those caching mechanisms without danger for your data. CACHEnnn is no separate cache program; it just extends GEMDOS' internal sector buffer list. This won't collide with any external caching by hard disk drivers etc. (if properly done, of course). ---------------------------------------------------------------------- Claus Brod, Am Felsenkeller 2, Things. Take. Time. D-8772 Marktheidenfeld, West Germany (Piet Hein) csbrod@medusa.informatik.uni-erlangen.de ----------------------------------------------------------------------
andyc@hplsla.HP.COM (Andy Cassino) (10/30/90)
david@doe.utoronto.ca (David Megginson) asks: | | Now, how should I set up caching for the best effect under TOS 1.4? | I have turned off write caching in the ICDBOOT driver (it scares | the dung out of me), but I have to choose among using only | Atari's CACHEnnn.PRG (which is _very_ fast), ICDBOOT's built-in | read caching, or some combination of the two. Any suggestions? Is | CACHEnnn.PRG safe to use with ICDBOOT, or does it need AHDI? | Good questions! It will be interesting to hear what folks have to say. I use a cache mostly to speed up compiles, so that's how I test a cache. Otherwise, I'm not an expert on this topic, so if I make some erroneous statements, take it easy, ok? I find the ICDBOOT built-in cache, Atari's CACHEnnn, and the cache included with DiamondBack 2.xx to be roughly equivalent in performance for compiling. I understand that DiamondBack has special hooks into it's cache that allows for faster backups than could be obtained with the other caches. I haven't tested this. I only use the DiamondBack cache now, because it's desk accessory allows for the most convenient adjustments to the configuration, and because I can always be ready for a quick back-up. Also, the desk acc maintains some statistics so it is easier to optimize the configuration. I also like the fact that I can pick which drives will be cached. ICD's and Atari's caches will cache everything - including a RAM disk, which is pointless. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Andy Cassino % % Hewlett-Packard - Lake Stevens Instrument Division % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
hyc@math.lsa.umich.edu (Howard Chu) (10/31/90)
In article <13510003@hplsla.HP.COM> andyc@hplsla.HP.COM (Andy Cassino) writes: >david@doe.utoronto.ca (David Megginson) asks: >like the fact that I can pick which drives will be cached. ICD's and Atari's >caches will cache everything - including a RAM disk, which is pointless. Hm. With sufficient memory and a good cache, isn't the whole idea of a RAMdisk pointless? I'm hearing conflicting info on Atari's CACHENNN.PRG. Does it only cache FAT and directory info, or also data sectors? The behavior appears a little erratic to me, showing disk hits when I wouldn't expect any to occur... -- -- Howard Chu @ University of Michigan Mac// - adv., q.v. MacToo, e.g. McHave a McHappy McDay! McThanks, McYou MacToo!
csbrod@medusa.informatik.uni-erlangen.de (Claus Brod ) (10/31/90)
hyc@math.lsa.umich.edu (Howard Chu) writes: >I'm hearing conflicting info on Atari's CACHENNN.PRG. Does it only cache >FAT and directory info, or also data sectors? The behavior appears a little >erratic to me, showing disk hits when I wouldn't expect any to occur... It buffers both. Well, to be more correct: CACHEnnn itself buffers nothing at all. It just extends the internal GEMDOS sector buffer list. So if you find any erratic behavior concerning caching, blame it on GEMDOS. ---------------------------------------------------------------------- Claus Brod, Am Felsenkeller 2, Things. Take. Time. D-8772 Marktheidenfeld, West Germany (Piet Hein) csbrod@medusa.informatik.uni-erlangen.de ----------------------------------------------------------------------
ngse18@castle.ed.ac.uk (J R Evans) (10/31/90)
hyc@math.lsa.umich.edu (Howard Chu) writes: >Hm. With sufficient memory and a good cache, isn't the whole idea of a >RAMdisk pointless? Not in all cases (and that's true, even on machines with virtual memory). To take the example of compilation: most compilers produce a significant number of temporary files at various stages, which persist for only a few seconds before they are deleted. [GNU cc is an exception here - this is one of the reasons it's a memory hog]. At the same time, to the best of my knowledge, all the software caches for the ST are 'write-through'. This means that all files are actually written out to disk as they are made. [Again, if there are 'intelligent' caches out there, given TOS's insecurity, *I* wouldn't risk my data by using them in a development environment]. So, during a typical compilation, even though a cache will generally give an improvement in runtimes over no cache, use of a RAM-disk for temporary files will (except in some *very* particular cases) be even faster. The choice as to whether to use a cache and/or a RAM-disk is very dependent on the particular work being performed. Especially on a single user machine like the ST, the appropriate choice will probably be different for the same user on different occasions [I certainly adjust these choices on my ST system - often several times within a session]. This is an example of system tuning. As an illustration of how bizarre it can get, I have an old PDP-11 which is largely used for program development. Of 4Mb memory, 3Mb is used as a RAM-disk, 740k as disk cache, and only 256kb as system memory space - odd, but that's the way it functions best *for that application*. Russ
stephen@oahu.cs.ucla.edu (Steve Whitney) (11/01/90)
In article <1990Oct30.220831.17172@math.lsa.umich.edu> hyc@math.lsa.umich.edu (Howard Chu) writes: > ... >Hm. With sufficient memory and a good cache, isn't the whole idea of a >RAMdisk pointless? > Well, I use one on my four meg STE for all of the obnoxious temporary files that Mark Wiliams C insists on writing all the time. The GEMDOS caching scheme is a write-through cache (which I appreciate whenever I crash my system testing a program or someone turns my machine off!), but that means that You still at least have to write the temporary files out to disk before they get cached. In an ideal worls, the compiler would see tht it had enough memory and use it. No, I take that back. In an ideal world, we'd have virtual memory so the compiler could _always_ use RAM... The OS would decide when it should go to disk! > -- Howard Chu @ University of Michigan > >Mac// - adv., q.v. MacToo, e.g. McHave a McHappy McDay! > McThanks, McYou MacToo! -- Steve Whitney "It's never _really_ the last minute" (())_-_(()) UCLA Comp. Sci. Grad. Student | (* *) | Internet: stephen@cs.ucla.edu UCLA Bruin--> { \_@_/ } GEnie: S.WHITNEY `-----'
andyc@hplsla.HP.COM (Andy Cassino) (11/01/90)
Howard Chu asks: > Hm. With sufficient memory and a good cache, isn't the whole idea of a > RAMdisk pointless? ---------- Not entirely. I use Mark Williams C, which, as a three pass compiler writes lots of temporary files, not to mention the object files and the link file. I use a RAM disk to minimize the fragmentation on my hard drive, caused by all this file creation/deletion. The cache is to speed up access of the various programs, include files and libraries that the compilation needs. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Andy Cassino % % Hewlett-Packard - Lake Stevens Instrument Division % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
apratt@atari.UUCP (Allan Pratt) (11/01/90)
People seem a little unsure of how GEMDOS's cache (the one CACHEXXX.PRG adds to) works. There are two lists of buffers. CACHE030.PRG, for example, will add 30 buffers to each list. You can give it arguments to explicitly give a certain number to each list. Both lists are write-through: all writes happen right away. The first list caches FAT and root directory sectors. Any FAT or root directory access will use this cache. The second list caches data sectors, defined as those which aren't FAT or root directory. Subdirectory sectors always use this cache. Normal file data sectors only use this cache if your program doesn't do reads and writes of complete sectors. Then the data sector is read into the cache, and the piece your program wanted is copied. Whole-sector or multi-sector reads and writes don't use the GEMDOS cache at all. They always go straight to disk. That's where the other caches in the world can help. With enough cache buffers, all of the FATs and root directories on all of the drives on your system will end up in the first cache and never be replaced. It's a waste of space to have more sectors in the first list than you have FAT and root directory sectors. Having a lot of buffers in the data-cache list will mean that all your subdirectory sectors will get cached, and in addition the parts of files that get accessed as fragments, not as whole sectors. One example of this kind of access is in GEMDOS itself: Pexec reads the header of a file to find out how big it is, and since the Pexec routine only wants $1c bytes of data, the sector lands in the cache. Then, Pexec reads the text+data part of the file, and since it probably doesn't end on a sector boundary that last sector winds up in the cache. Finally, Pexec reads the fixup information, and that probably doesn't begin or end on sector boundaries, resulting in two more fragments. (The end of the text+data and the beginning of the fixups will be the same place unless there are symbols in the file.) You can tell if you have "enough" sectors in each list by doing a "show info" from the Desktop on all your drives, then doing it again. If the second time doesn't actually hit any disks, it means all the FAT, root directory, and subdirectory sectors are in the cache. Both caches are managed LRU: each time there is a "cache hit" on a buffer, it gets moved to the beginning of the list, and when the time comes to replace a buffer, the replacement is chosen from the end of the list. All this information is subject to change: I make no guarantees about the workings of GEMDOS's cache system past, present, or future. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
gl8f@astsun.astro.Virginia.EDU (Greg Lindahl) (11/01/90)
In article <6948@castle.ed.ac.uk> ngse18@castle.ed.ac.uk (J R Evans) writes: > At the same time, >to the best of my knowledge, all the software caches for the ST are >'write-through'. This means that all files are actually written out >to disk as they are made. [Again, if there are 'intelligent' caches out >there, given TOS's insecurity, *I* wouldn't risk my data by using them >in a development environment]. Laser C has a file-level cache which is write-through for your source code and delayed write-back for temporary files, object files, and executables. It's amazingly easy to use, and much better than a RAM disk as it's dynamic and you don't have to set anything up to use it. On a 1 meg ST with floppies it must be a godsend -- even with a HD, it's quite nice.
woju@mist.UUCP (Wolfgang Jung) (11/02/90)
In <1990Oct30.220831.17172@math.lsa.umich.edu>, Howard Chu writes: }In article <13510003@hplsla.HP.COM> andyc@hplsla.HP.COM (Andy Cassino) writes: }>david@doe.utoronto.ca (David Megginson) asks: }>like the fact that I can pick which drives will be cached. ICD's and Atari's }>caches will cache everything - including a RAM disk, which is pointless. } }Hm. With sufficient memory and a good cache, isn't the whole idea of a }RAMdisk pointless? } }I'm hearing conflicting info on Atari's CACHENNN.PRG. Does it only cache }FAT and directory info, or also data sectors? The behavior appears a little }erratic to me, showing disk hits when I wouldn't expect any to occur... It should does both ! But i don't know if the CACHEXXX.prg will work with the BGM Partitions, which will be created for Partitions >32 MB So be careful! By -- Bye,... Don't trust your eyes. It's just an imagination of your brain ! woju@mist.UUCP(only subnet), woju@image.in-berlin.de woju@neon.in-berlin.de (c) by Wolfgang Jung, Berlin (date look at header !!)
GERLOFF@tubvm.cs.tu-berlin.de (Olaf Gerloff) (11/06/90)
In article <A0avg4qi@mist.UUCP>, woju@mist.UUCP (Wolfgang Jung) says: > >It should does both ! But i don't know if the CACHEXXX.prg will work >with the BGM Partitions, which will be created for Partitions >32 MB > Hello Wolfgang! CACHEXXX.PRG gets the size of the logical sectors of the HD partitions from the driver. It will adjust the size of the reserved buffers, so that it will be the same as the biggest logical sector of your GEM or BGM partition. I use a 48 MB BGM partition with AHDI 3.01 and CACHEXXX.PRG and there are no problems. Greetings, Olaf