Hi, I have uploaded a new LBAcache devel version: http://www.coli.uni-sb.de/~eric/stuff/soft/ lbacache-09jun2004.zip
This version limits the search range for every cache hit / miss event to 16 elements. This means "if it is not in one of 16 possible elements then it must be a miss" and "if it was a miss, allocate one of the 16 possible elements". The latter tries to use the element which is least important (least used so far). The 09may2004 version of LBAcache, on the other hand, searches ALL elements until it is sure of a miss (however 256+1 recently used elements are memoized, so a cache hit usually does not trigger this big search). If it had a miss, it allocated one of ALL possible elements in a simple round robin fashion, only skipping over locked elements (locked elements are only possible if you manually edit the element table in RAM - some future tools might do that). Theory tells that LBAcache 09may2004 has better cache hit ratio while LBAcache 09jun2004 should consume less CPU cycles (and less table reads, which is important if you load LBAcache into a slow RAM area like the hardware UMBs on certain hardware). If cache hit ratio drops too much for you, then overall disk access speed will probably be worse. I tried to tune the hashing function which selects the "range of 16 possible elements which will be searched" to avoid this. My hope is that LBAcache will work better especially on slow computers without working worse on fast computers. Biggest speed differences will probably exist for really big caches in slow UMBs on 486/Pentium systems or something like that. To display cache statistics, use the "new" LBACACHE STAT command. Easier to read than the old and still supported INFO stuff. Please test (Hi Justin! :-)) and let me know if this is a promising update. Thanks! Eric. PS: TICKLE(HD) now allows case-insensitive options (old: HD, LB / new: chs, lba ...) for harddisk readahead. And it refuses to load into too small UMBs now. PPS: You can use the FreeDOS RUNTIME command as stopwatch to measure speeds. PPPS: If cache hit percentage drops more than you want it to drop, try using a somewhat bigger cache. The new 16 way associative access scheme gives the cache less flexibility to evenly spread sectors across the whole XMS chunk. So the cache will earlier start re-using elements even though elements at other places in the cache would have been completely free. Alas there is no count of used / free elements in LBACACHE STAT display yet. Try debug :-). Segment is signature segment and offset is table offset. Each element has 8 table bytes. [32bit sector, byte drive, byte usagecount, word sectorbitmask. For unused elements, sector is -1 and drive / usagecount / sectorbitmask are all 0... Maybe somebody could write a nice "used / free elements and usage counts histogram" (etc.) visualization tool for LBAcache...?] ------------------------------------------------------- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
