Hi, I have added the user-friendly command line and statistics display features which I have added to LBAcache a few days ago to CDRcache now.
*** Note that if you are an NDD user you should re-download lbacache-09may2004 *** because the initial version had a typo in the code which spoiled the *** protection from "panic if > 1024 cyl accessed through special functions". Whatever. So what changed in CDRcache now? http://www.coli.uni-sb.de/~eric/stuff/soft/ cdrcache-13may2004.zip (66k) - the new version allows more intuitive command line syntax: DEVICE=...CDRCACHE... FDCD0001 CDRCACH$ 4096 loads a cache of 4096k (4 MB) size which will connect to the FDCD0001 device (I assume you used this name for your CD-ROM driver) and will call itself CDRCACH$ (you can give this name to SHSUCDX to connect to the cache(d drive)). The old syntax is still supported as well: DEVICE=...CDRCACHE... FDCD0001 CDRCACH$ 16 where the value 16 (range: 1..99) means 16/4 MB size. - the new version displays shorter statistics. Example use: echo s > CDRCACH$ displays short and "easy to read" statistics. Decimal numbers have leading zeroes suppressed in the statistics display. You can still get the old (verbose / technical) statistics display as "tech info": echo i > CDRCACH$ ... and "echo ? > CDRCACH$" still shows some help message. - the command line help (displayed if a syntax error happens or when you do DEVICE=...CDRCACHE... /? as usual) has been improved and now tells you about the "echo ... > ..." control interface. CDRcache can be loaded with DEVLOAD (e.g. the upcoming version 3.13, which is the same as 3.12 except for the /Q (quiet) command line option having a much stronger effect to reduce unwanted screen output), but you must load it before connecting to it with SHSUCDX or similar drivers, obviously ;-). SHSUCDX / similar will only be able to connect to the cache(d drive) if you have the CDRcache device in the device chain, so I will *not* release a .com version of the driver. DEVLOAD has to do quite a bit of work to plug drivers into the device chain, so I am not planning to put the whole "DEVLOAD engine" inside an CDRcache.com binary. Please test and let me know if there are any new bugs. Be warned that using some huge cache size like 48 MB will probably cause big CPU load, so performance can be worse for bigger caches, which might be not-so-intuitive. Element size is still 16 kB (can be up to 32 kB, CD-ROMs use 2048 bytes per sector). Especially cache misses can be slow: Both LBAcache and CDRcache are fully associative at cache element level. This means that every element (which consists of several consecutive sectors) can be stored everywhere in the cache. Recently used elements (256+1 of them) are stored in a quick find table, so cache hits have considerably lower average penalty CPU load wise. Cache misses, on the other hand, mean that the whole cache has to be searched to make sure that the data is not stored anywhere in the cache yet. Checking the quick find table is not enough there. Old versions of LBAcache were extreme in the other direction: One version was 1-way associative, which means that for every element only one position in the cache (computed from the position on disk) is possible. No searching at all, fast. But not performing well, because the cache is much smaller than the disk: Many disk sectors are sharing the same element slot, sectors often fight to get that one possible slot while many other slots remain empty. I think future versions (only binsel*.asm has to be changed) will have some in-between associativity. For example every disk location can be assigned to a range of N element slots (N way associativity!?). Then you always have the CHOICE between N elements and have to SEARCH at most N elements to find the data in the cache. Because I have the quick find table, I tend to make N rather big, e.g. 16 or more. A fun idea seems to start searching at slot number (NSLOTS * hash8(...) / 256) (NSLOTS being the number of element slots for the current cache size, hash8(...) being an 8 bit hash of the disk location) and then search at most those N slots. That way, the possible slot ranges for each disk positions can overlap. Objections against that? Recommendations for the value of N? I feel that N should be at least 4 to have enough flexibility, but also much smaller than NSLOTS for speed reasons, especially for huge caches (big search with big N) and / or huge drives (too many collisions if too little flexibility / too small N). At least this is no hardware cache, so *searching* N slots can be done with a loop. In hardware caches (for RAM, e.g. CPU L1 / L2 caches), N is often very small (1..4) because the search result has to be ready "at once" and all comparisons are done in parallel (needs many transitors). Let me know what you think about the "associativity way-ness parameter" selection problem... Thanks for your feedback. *** Suggestion for the news item text: Hi, I have added the user-friendly command line and statistics display features which I have added to LBAcache a few days ago to CDRcache now. Get it from http://www.coli.uni-sb.de/~eric/stuff/soft/ cdrcache-13may2004.zip (66k). Improvements: New (easier to read) statistics display. Old display still available as techinfo display. Cache size can now be given in kilobytes (old units of 1/4 MB still possible in 1..99 size range), maximum cache size 65280 bytes. Improved help messages (at load time and in the echo-to-device user interface). *** End of suggested news item text. CDRcache (with the current 16k element size setting) will use 5.5 + (X/2) kilobytes of RAM for cache sizes of X megabytes of XMS. Happy caching! Eric. ------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
