Hi all,
based on the "remote controlled" (over IRC) tests with Tylers SCSI test
system, I have now added a new switch to LBAcache: "TUNS". If you use
the TUNS option, and LBAcache detects that it is about to load to UMB,
it will allocate 320 bytes of LOW DOS RAM (outside UMB, you guessed it)
for the local stack. This stack is even used during initialization,
as (remember my "Tyler test result mail") we found out that having
the stack in UMB in combination with UMBs being provided by EMM386
does even break the seemingly trivial "geometry query" (int 13.8)
in SCSI BIOSes, possibly due to DMA-to/from-stack issues in there.
Please let me know if you can now use
LOADHIGH LBACACHE TUNS ...
without problems even for the combination EMM386/SCSI! To compare:
LOADHIGH LBACACHE ...
without the TUNS option, as well as using older versions of the
cache, will result in very slow and unsuccessful (int 13.8 returns
timeout error for some funny reason) initial drive detection.
Other news: Geraldo Netto did a few LBAcache "TUNA" and "TUNW" (but
not yet "TUNA and TUNW") benchmarks. TUNW increases write hit percentage
considerably (it was always on in old cache versions) without lowering
read hit percentage in usual situations. So I guess you can have it on
most of the time. The other flag, TUNA, on the other hand, only increases
hit percentage a little bit, while increasing CPU time a lot. Most of the
2003/2004 versions of my cache were always in "tuna mode" (;-)), so I
recommend that you do NOT use TUNA - you will gain speed and have only a
few extra disk accesses. So the non-TUNA "16 element set associative"
mode which I have recently added does indeed seem to work fine :-).
It was also Geraldo who pointed out ("long ago") that 8k element size
gives almost as good hit percentage as 4k: Because LBAcache uses less
DOS RAM the bigger the elements are (with SMARTDRV it is the opposite
direction, because of the local element buffer), that was a quite useful
hint back at the time. Element size has been big since then.
http://www.coli.uni-sb.de/~eric/stuff/soft/ lbacache-24jul2004.zip
is the new version, get it and enjoy... And tell about SCSI improvements.
For a possible news item (I prefer first waiting for SCSI feedback)...
I have uploaded a new version of LBAcache, which now offers a TUNS
command line option. This option should help to solve problems which
happen when you LOADHIGH LBAcache and have a SCSI system. Symptom of
the problem was: drive detection took very long and finally decided
that there would be no harddisks. Cure: TUNS now allocates the stacks
for LBAcache in low DOS RAM, below UMB area, hopefully solving DMA problems.
First benchmarks of the previous version suggest that LBAcache works
faster in 16 way set associative mode than in classic fully associative
mode, so I recommend not using the TUNA (re-enable classic) mode unless
you want maximum hit ratio for a relatively small cache. The TUNW option,
on the other hand, seems to be optimally on (as in classic mode), turning
it off only reduces cache "flooding" in certain special situations. Read
the documentation for more details.
Eric
PS: The new low "TUNS" stack - only used if LBAcache is in UMB and you
used the TUNS option when loading it - will stay allocated in memory even
when you unload the cache later. Sorry about that, but it's only 320 bytes
anyway and the unloading protocol would have gotten far more complex otherwise.
-------------------------------------------------------
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
