Hi, I have updated LBAcache, please test http://www.coli.uni-sb.de/~eric/stuff/soft/ lbacache-15jul2004.zip
(122k, including updated DOCUMENTATION...) Changes: 15.07.2004 Fixed a bug in "block NDD int 13.ee/13.ef access" (added 01.05.) accidentally blocked other functions as well, in particular int 13.41/13.48 (check for LBA, get LBA info) which are used by tools like Partition Magic. New command line options: Alloc on write "TUNW" (was on all the time in older versions) and full associativity "TUNA" (i.e. revert to pre 9.6. behaviour). Changed files: cmdline.asm, dispatch.asm, write.asm, binsel2.asm If you are running any version in 1.5.-17.6. range, LBA-aware DOS programs will believe that your system supports no LBA, so an update is recommended. Other bugs in older versions: 9.6. will occasionally access out-of-range XMS areas (potentially serious problem), 1.5. and older versions have no proper support for 1.68 MB floppy format (hint: DOSFSCK, FORMAT and kernel have proper support, but most other disk tools do not. Normal tools are no problem as the kernel does the work for them). New command line options: TUNA Fully associative cache: Search whole cache for a sector or for free space in worst case. Slower for big caches but can give more cache hits than the new (6/2004) default of searching only up to N (current setting: 16) cache elements (current size of an element: 8kB). Please TELL ME how much this changes speed and cache hit percentages for YOUR own test scenario, thanks! TUNW Allocate on write: When data is written to disk, store a copy in cache, EVEN if that means allocating new space in cache, in anticipation of reading the data back later. Was the default until 7/2004. Makes writes "consume" more cache, but is useful for tasks which work with temp files a lot. If data was cached anyway, the copy in cache is updated regardless of this option. Unless you use the TUNW option (or have a pre-7/2004 LBAcache version), the cache contents will stay untouched in case of a write miss. ELSE, a "write miss" means that LBAcache stores a copy of the written sector in the cache - because it assumes that the sector will eventually be read later. Then the read can be served from cache without having to access the disk. But the write itself is always passed to disk at once. As a rule of thumb, use TUNW if your program uses temporary files or swap files a lot. If it just produces a lot of data but you do not need the data again right after that, *not* using TUNW will leave more space in the cache for caching reads. The TUNA switch simply makes LBAcache use the old "allow every disk sector to be stored anywhere in cache RAM" behaviour. For cache hits, search time (at least on average) is quite fast because of the memoization (content- addressed memory) buffer (stores 256+1 recently used element positions), but for memoization misses the whole cache has to be searched to find out whether a real cache miss has happened (required to keep the cache in a consistent state). For big caches this can mean quite slow access in times of many cache misses. I am VERY interested in getting reports about effects of the TUNA switch - first tests suggest that unless your cache size is quite small TUNA will not improve cache hit percentage much. DOS caches are of course a bit boring if your IDE disk has 8 MB built-in cache anyway :-). Only combine TUNA with a huge cache if it is very important for you that the disk is not accessed often, even if that means more CPU cycles spent for caching. Actually even a 7200rpm ATA133 disk takes only < 10 Watts when busy but keeping your CPU exceedingly busy can waste much more than that. The TUNW switch is inspired by comparison to other caches: Those just let writes to uncached sectors happen, without storing a copy for later reference, unless you activate delayed writes (NOTE: LBAcache never delays writes!). I had reports that this allows the cache to focus more on caching read data, so the new default is not to save a copy of written data unless it is needed (if the affected sector is already in cache, you must of course update cache contents when the sector on disk is written to). I think that this will be better for some write-intensive tasks like installing software. For *other* tasks, e.g. running compilers or browsers which use many temp files which are written and then read back shortly after that, please do enable the TUNW switch to get the "classic LBAcache" behaviour, which should be better / faster for *those* scenarios. Please test, thanks! To report effects of TUNA / TUNW / none-of-both / both, please tell 1. which command line you used to load the cache 2. what you have done as test task 3. the time it took to complete the task 4. the output of LBAcache STAT (only the relevant lines of it) at the end of the task. All 4 items for at least 2 different command lines of LBAcache, of course, or alternatively for 1 LBAcache command line and 1 way to use another cache. Reboot or unload caches between tests (obvious...). If the other disk cache to which you compared LBAcache allows delayed writes, please disable them to allow better comparison (or contact me if you want to test the effects of delayed writes themselves, I have some detailed wishes for such testing...). Eric [Thanks to J.Seifert for telling me about P.Magic problems and suggesting a fix!] ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel