blgardne@esunix.UUCP (Blaine Gardner) (05/31/87)
A mini review of Facc.
Facc is ASDG's Floppy ACCelerator. It is an intelligent disk cache
program. It comes packaged in a Compact Disk jewel box. There is a small
insert showing the Facc window, but the main documentation is on the
disk. The documentation does a good job of explaining Facc, and disk
caching in general. One thing not mentioned is that one buffer = 544
bytes, useful for setting the number of buffers desired.
Facc couldn't be easier to use, simply run it from the Workbench or CLI.
Facc is now active, and opens a window that shows free memory, number of
buffers, reads, writes, hits, and percentage of hits. The number of
buffers is controlled by two gadgets, and the window can be shrunk by
another.
Facc comes up with 256 buffers (139,264 bytes) as the default. This is
easily changed from the Facc screen, but I wish there was a command line
argument for setting the number of buffers. As long as memory is
assigned to buffers, it can't be used by anything else (unlike the
maximum size of the RRD). If you run short of RAM, click on the "Fewer"
gadget.
One nit-pick. It is stated that "Facc presents a graphic display
detailing cache effectiveness...". Um, no. Facc puts up a display all
right, but it's a text display, not a graphic display.
I don't have any benchmarks, but the subjective speed increase is
incredible. After the first read that is, there's no change in speed on
the first time data is read in. I have 2.5 Meg of RAM on my Amiga, and
I've been running with 512 buffers (278K). I don't know how useful Facc
would be on a 512K Amiga, but with plenty of memory, it makes a huge
difference in the way the Amiga feels.
Another important fact is that Facc buffers come out of Fast RAM, not
Chip RAM.
Highly recommended!
--
Blaine Gardner @ Evans & Sutherland
UUCP Address: {ihnp4,decvax}!decwrl!esunix!blgardne
Alternate: {ihnp4,seismo}!utah-cs!utah-gr!uplherc!esunix!blgardnerokicki@rocky.STANFORD.EDU (Tomas Rokicki) (06/01/87)
In article <326@esunix.UUCP>, blgardne@esunix.UUCP (Blaine Gardner) writes: > caching in general. One thing not mentioned is that one buffer = 544 > bytes, useful for setting the number of buffers desired. Perry! Why couldn't you have used the AvailMem lists and used *all* *free* *memory*? This is what I was afraid of . . . I don't want to set another buffer size which I shouldn't need to set!
walton@tybalt.caltech.edu.UUCP (06/02/87)
In the referenced article, Blaine Gardner posts a quite favorable
review of Facc. I second that recommendation, with some measurements
attached.
While the long time it takes to open a Workbench window is
annoying, the most time-consuming thing I do with my Amiga is "make".
So, I made some measurements to try to determine how much time Facc
saves me, and how many Facc buffers are required. I used a floppy
with the MicroGnuEmacs Amiga and system-independent sources and did a
"make mg" with Facc installed at its default 256 buffers, and with the
number of buffers bumped to 512. A clean copy of Facc was invoked
both times, and the objects and executables were deleted in between.
With 512 facc buffers, "make mg" took 19 minutes. 256 facc
buffers raised that to 34 minutes. Facc's display showed a very low
hit rate with 256 buffers (below 10% for both drives); 512 buffers
increased this to 90% for my compiler disk and almost 70% for the Mg
disk. Similar results were obtained for "make shell." So, it appears
that increasing the number of buffers past 512 wouldn't help this
particular application much.
A few comments: Facc considers a block which is written to a
disk as one which has been referenced, making the assumption that when
a file is written it will almost immediately be used as input to
another program. I don't know to what extent this is correct, and
would have liked to try a version which ignored written blocks and
used read accesses alone as its criterion for which blocks to keep.
Also, facc treats all blocks as alike, and some kind of priority
scheme would help keep directory blocks in memory longer. Perhaps
Facc could count the number of times one of its cached blocks is
accessed, and reuse the ones with the smallest count first; I suspect
this might add considerably to Facc's overhead, though.
Finally: it is both fun and enlightening to watch Facc's display
of disk read and write accesses. A double-click on a drawer on my
Workbench disk containing 10 tools and associated icons generated 55
(yes, 55!) read requests.
Steve Walton, guest as walton@tybalt.caltech.edu
AMETEK Computer Research Division, ametek!walton@csvax.caltech.edu
"Long signatures are definitely frowned upon"--USENET posting rulesrokicki@rocky.UUCP (06/03/87)
walton@tybalt.caltech.edu (Steve Walton) writes: > Perhaps > Facc could count the number of times one of its cached blocks is > accessed, and reuse the ones with the smallest count first; I suspect > this might add considerably to Facc's overhead, though. Implementing a simple LRU queue would introduce almost zero overhead (move a couple of links for each block accessed; very fast) but would probably keep directory blocks around . . . is not this how facc does it? Perry? -tom
perry@well.UUCP (06/03/87)
In article <338@rocky.STANFORD.EDU>, rokicki@rocky.STANFORD.EDU (Tomas Rokicki) writes: > In article <326@esunix.UUCP>, blgardne@esunix.UUCP (Blaine Gardner) writes: > > caching in general. One thing not mentioned is that one buffer = 544 > > bytes, useful for setting the number of buffers desired. > > Perry! > > Why couldn't you have used the AvailMem lists and used *all* > *free* *memory*? This is what I was afraid of . . . I don't want to > set another buffer size which I shouldn't need to set! Are we reading each other? Facc allows buffers to be added or taken away at will (at any time). Why would you want to take up ALL of memory with disk buffers automatically? What's the beef here? Pooh. Perry
mwm@eris.UUCP (06/03/87)
In article <3204@well.UUCP> perry@well.UUCP (Perry S. Kivolowitz) writes: <In article <338@rocky.STANFORD.EDU>, rokicki@rocky.STANFORD.EDU (Tomas Rokicki) writes: <> Perry! <> <> Why couldn't you have used the AvailMem lists and used *all* <> *free* *memory*? This is what I was afraid of . . . I don't want to <> set another buffer size which I shouldn't need to set! < <Are we reading each other? Facc allows buffers to be added or taken away <at will (at any time). Why would you want to take up ALL of memory with <disk buffers automatically? What's the beef here? < <Pooh. < Perry No, you're not reading each other. What Tom wants is for the buffer cache to automatically use memory as it's freed, and automatically give up buffers when memory gets tight, preferably by replacing the memory management routines with your own. In other words, to always be using all of free memory. While I'm here (really, the justification for posting), I'd like to ask some questions about FACC: 1) Is there any way to make the window attached to it go away? Or at least make it small enough to hide under a menu-bar clock? Unless I'm tuning the thing, I don't want some extraneous window cluttering up my display. 2) What happens if I tell it to use lots of buffers, then need the memory back? For example, I've got a full C development system loaded and running (even as I type; a multi-tasking terminal is a thing of joy), and have 2493K of free FAST memory - I'd like to give the buffer cache 1760K of that. Later, I want to load something else, and forget that I've got FACC running with lotsa-buffers. Will I just run out of memory, or will FACC be intelligent and size itself downward? Basically, the second question reiterates what Tom was asking: does FACC pay any attention to how much free memory is left? If not, then ASDG has managed to produce another really spiffy piece of software with just enough design misfeatures (in this case, one) to be unusable in a fair number of environments. <mike -- How many times do you have to fall Mike Meyer While people stand there gawking? mwm@berkeley.edu How many times do you have to fall ucbvax!mwm Before you end up walking? mwm@ucbjade.BITNET
perry@well.UUCP (06/04/87)
First I would like to thank Steve Walton and Blaine Gardner for their contributions to (my) understanding of Facc and what features are considered important for adding to Facc. As Facc is ASDG's first commercial software product we are new to the software packing business - we did not state any upgrade policy on or in the package. It is the following: Owners of Facc simply send their original disk with a stamped self-addressed envlope and we'll send an updated copy - forever (or as long as ASDG is a viable business concern which we plan on being as close to forever as we can make it :-) The next version will have exactly what the two persons referenced above have suggested - and will be available in the next few months - and you know me, as soon as it's available - you'll hear about it :-) So as it stands - the current rev of Facc *is* extremely useful as it stands as reported by two (and actually many more) unbiased reviewers. And, we have a planned series of improvements with totally free upgrades. Not a bad start at the software biz eh? Perry S. Kivolowitz By the way - here's DiskPerf benchmarks (68010, 1800 buffers) Creations: 0/sec Deletions: 32/sec Directory Scan Rate: 44/sec Seek/Read: 133/sec Read (512) 81920 Write (512) 5589 Read (4096) 124830 Write (4096) 5748 Read (8192) 131072 Write (8192) 5723 Read (32768) 137970 Write (32768) 5736
perry@well.UUCP (06/04/87)
In article <344@rocky.STANFORD.EDU>, rokicki@rocky.STANFORD.EDU (Tomas Rokicki) writes: > walton@tybalt.caltech.edu (Steve Walton) writes: > > > > (talks about popularity based replacement algorithm) > > (talks about LRU based replacement algorithm) Tomas And Steve, I had considered the popularity based replacement algorithm but rejected it due to the simplicity inherent in the LRU algorithm which Facc *does* use. Actually, there are three principal lists kept within the Facc buffer structure coming together in a data structure which al- lows Facc to search 2048 buffers in the time AmigaDOS will search 16 buffers allocated with AddBuffers. The next version of Facc (as mentioned in a previous note, Facc will have ``perpetual'' support to owners) will have a modified LRU, something I've been cooking up. If that does improve things even more, I will implement the popularity code.
bakken@tahoma.UUCP (06/04/87)
[] In article <326@esunix.UUCP>, blgardne@esunix.UUCP (Blaine Gardner) writes: > > A mini review of Facc. > [ Blaine gives a useful review] > Highly recommended! > -- > Blaine Gardner @ Evans & Sutherland > UUCP Address: {ihnp4,decvax}!decwrl!esunix!blgardne > Alternate: {ihnp4,seismo}!utah-cs!utah-gr!uplherc!esunix!blgardne But how much does it cost?? Boeing Commercial Airplane Company uw-beaver!ssc-vax!shuksan!tahoma!bakken (206) 237-5890 My views are my own, not my employer's. Don't let them deter you from buying the 747 you've been saving hard for.
stever@videovax.Tek.COM (Steven E. Rice, P.E.) (06/04/87)
In article <338@rocky.STANFORD.EDU>, Tomas Rokicki (rokicki@rocky.STANFORD.EDU) suggested that Facc should automatically use whatever memory was available. Perry S. Kivolowitz (perry@well.UUCP) responded (in article <3204@well.UUCP>): > Are we reading each other? Facc allows buffers to be added or taken away > at will (at any time). Why would you want to take up ALL of memory with > disk buffers automatically? What's the beef here? I can't be sure what Tomas had in mind, but what I would like to see is automatic deallocation and allocation of buffers as other programs allocate and free memory (respectively). This way, your performance would vary, depending on what and how much you were trying to run, but you wouldn't be as likely to get "out of memory" aborts. > Pooh. What does a bear of very little brain have to do with Facc? (My kids like the program, if that helps. . .) Steve Rice ----------------------------------------------------------------------------- new: stever@videovax.tv.Tek.com old: {decvax | hplabs | ihnp4 | uw-beaver | cae780}!tektronix!videovax!stever
perry@well.UUCP (06/05/87)
Mike,
(1) The current version of Facc does shrink its window at the touch of
a button.
(2) The current version of Facc allows the user to decrease the number
of buffers again with the touch of a button but not automatically.
(3) ASDG's support policy is that forever, simply send in your original
floppy and get the newest version of Facc.
(4) A new version of Facc based upon ALL of the worthwhile comments pre-
sented in this news group will be included. The commentary of this
news group has followed (exactly) the thinking we've been doing here
for the next version.
(5) The new version of Facc *will* have one neat feature that usenetters
haven't thought of yet - but knowing the net - you probably will
soon :-).
(6) The current version of Facc *is* useful and usable. Poeple love
it.
(7) Whattaya mean ``another'' misfeatured product? How much did you
pay for the RRD (if that's what you mean) and what are it's
misfeatures? :-) (don't reply to the net ok?) Recalling that the
RRD is almost a year old and was written at a time when most people
were figuring out how to open windows let alone device drivers and
the fact that we distributed it basically freely you shouldn't
have any complaints. Besides, wait till you see the next one.
(extremely mild flame off - all in good fun - no need to reply)
Cheers, Perry dillon@CORY.BERKELEY.EDU (Matt Dillon) (06/05/87)
> I had considered the popularity based replacement algorithm but >rejected it due to the simplicity inherent in the LRU algorithm which >Facc *does* use. Actually, there are three principal lists kept within >the Facc buffer structure coming together in a data structure which al- >lows Facc to search 2048 buffers in the time AmigaDOS will search 16 >buffers allocated with AddBuffers. In other words, the implementation in AmigaDoG is probably a linear search of its buffers... which is a big no-no for buffer caches. A hash table of some sort (which is what I assume Perry is using) of acceptable size usually provides an almost instantanious 'hit', and a somewhat slower (but still almost instantanious) 'miss'. Nobody says you can't also link each entry in a doubly linked list ordered for LRU.... That is, whenever a buffer is accessed it is moved to the head of the list. Thus, the buffers used the least float down to the end, and you remove them from the tail of the d-list when you (A) reach your max buffer limit, or (B) are tight on memory (etc...). Straight LRU basically implies that to realize a speed improvment on, say, a temporary file, the file blocks must fit completely in the buffer cache. One modification (which I doubt Perry is using, but *hey*, here's an idea for an improvement!), is to remove data blocks from the cache in reverse order on the assumption that if the file is too big for the cache, the second reading of the file will still find some blocks in the cache... a sort of "meet me in the middle" approach instead of "follow my tail", which gives no cache hits on the second go around for the file. Of course, there are many tradeoffs. In the most simplistic case, the above would only work well if the file blocks are sequentially accessed. -Matt
fox@mammoth.UUCP (06/05/87)
> >> I had considered the popularity based replacement algorithm but >>rejected it due to the simplicity inherent in the LRU algorithm which >>Facc *does* use... > One modification (which I doubt Perry is using, but *hey*, here's an >idea for an improvement!), is to remove data blocks from the cache in reverse >order on the assumption that if the file is too big for the cache, the second >reading of the file will still find some blocks in the cache... Perry, have you considered using the Optimal Page Replacement algorithm? I quote from "Operating Systems - Design and Implementation" by A. S. Tannenbaum: The Algorithm goes like this. At the moment that a page fault occurs, some set of pages is in memory. ... Each page [is] labeled with the number of instructions that will be executed before that page is [next] referenced. ... The optimal page algorithm simply says that the page with the highest label should be removed. Elegant, no? There is, however, some overhead involved in computing the labels... :-) David Fox
blgardne@esunix.UUCP (06/06/87)
in article <3223@well.UUCP>, perry@well.UUCP (Perry S. Kivolowitz) says: > > First I would like to thank Steve Walton and Blaine Gardner for their > contributions to (my) understanding of Facc and what features are considered > important for adding to Facc. > A few more suggestions Perry? 1) I don't care how you do it, but please find a way to give priority to directory information. Facc is great, but doing a large amount of I/O (copying large files for example) will flush the directories from the buffers. Having the directories in ram makes the greatest subjective speed improvement. 2) Change the "Expand" legend on the shrunken window to a display of free ram. Once you've used Facc for a day, you know that clicking on tiny window will expand it. And having the free ram display would be very useful. 3) "Beware of creeping featurism" as someone said, but I wish Facc would make the distinction between Fast and Chip ram in the free ram display. I've caused myself some trouble trying to balance a large number of buffers against a 1.5 meg vd0: (2.5 meg of ram), and forgetting that Chip ram was included in the total. 4) Provide a way to take bigger steps when changing the number of buffers. Right now it takes a while to move from 256 to 512 buffers. Perhaps a double-button click to step 100 buffers at a time. Overall Facc is a great addition to my Amiga, and with the free upgrade policy, I have to recommend it to everyone. -- Blaine Gardner @ Evans & Sutherland UUCP Address: {ihnp4,decvax}!decwrl!esunix!blgardne Alternate: {ihnp4,seismo}!utah-cs!utah-gr!uplherc!esunix!blgardne
perry@well.UUCP (Perry S. Kivolowitz) (06/09/87)
Blaine, Work on FaccII is proceeding apace. Your latest suggestion of replacing the word ``expand'' with the free memory count will be implemented. Some of the features of FaccII are: o Full programmers interface with full documentation. We will have a redistribution policy for application writers who want to include FaccII on their disk (and speak to it behind the user's back). o General purpose low-memory server chain. Any program will be able to request notification on low memory conditions. o Full command line interface for quick changes to Facc behavior. o Rapid/direct changes of buffer counts etc. o FaccII user agent plus FaccII replacing Facc with integral user agent - now the user interface can come and go (speaks to FaccII using the programmers interface). o Disableable retention on writes. o Four levels of replacements preferences/low memory handling. Current method (strict LRU), preference to directory blocks, and two others. o A lot more - plus other suggestions you might have. Again, the update policy on Facc is that updates are free with a self-addressed stamped envelope and your original disk - I will post here when FaccII is available (so don't let that stop you from getting Facc!).
perry@well.UUCP (06/12/87)
In response to a direct query, Facc is $34.95 suggested retail. For the remainder of June we will provide it direct from us at a $10 dis- count for usenetters. Future updates to Facc are free with your ori- ginal disk and a ``sase''. Perry S. Kivolowitz ASDG Incorporated (201) 563-0529