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
