Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

Comments On New 16-Nov-2009 UIDE. (Announce)

posted by Jack E-mail, Fresno, California USA, 22.11.2009, 04:35

>> The 16-Nov-2009 UIDE can cache up to 4 GIGABYTES of data!
>
> I thought due to PCI space (or whatever) that only 3.1 GB or such was
> generally accessible?
PCI addresses usually do not take more than 1-MB, unless a system has MANY
I-O devices. On my 1-GB system I can assign up to 1021 out of 1024-MB to
UIDE. DOS uses 1-MB, plus 64K for its HMA, and UIDE uses some XMS as its
cache-data tables. This is why I limit a 4-GB system to 4093-MB.

> I will have to try DEVLOADing this to see if it works. (I don't remember
> it being successful in the past, but I admit it's been a while.)
I last loaded UIDE with FreeDOS DEVLOAD about May of 2009, and I told Eric
Auer that his DEVLOAD worked O.K. This should still be so. If not, let
me know, and I will "Pull out a few more gray hairs!" and FIX this!

>> With /P, UIDE sets a 5-MB HMA cache only if /S5 is used and free HMA
>> allows this cache. The 5-MB cache runs slower, so it is "by request
>> only".
>
> I don't understand, 5 MB cache runs slower with /P or just slower than
> bigger caches in general? For instance, I always run a 5 MB cache on
> my P166 (only 32 MB RAM total).
Smaller caches must "discard" data more often, to make room for new data
being read or written. The 5-MB cache must "discard" almost everything
including directory data, if a file of over 2-MB is copied. UIDE needs
2-MB for the input copy, 2-MB more for the output copy, and shall likely
have to "give up" most stored directory sectors as well. The next file
will thus run slower, as DOS must re-cache all directory sectors. Only
then is DOS speed restored.

All of this is true with /P or without it. UIDE has a "least-recently-
used" (LRU) list that threads through all its cache-table entries, so it
"discards" only those sectors which are least-used on that list. But a
BIG new file can make UIDE discard EVERYTHING, as is true for any cache!

A "Rule of Thumb" for UIDE caches is that you should have (if possible!)
at least 3 times the cache space as your largest data file. Thus, UIDE
has room for an input copy, an output copy, and room so that directories
do NOT have to be "discarded", thus more data files are handled quickly!

Since "Vista" and other systems have MANY files at or near 2-MB, I chose
to have UIDE "default" to at least a 15-MB cache, if using HMA space, as
the 5-MB cache simply loses too much performance. Users that want 5-MB
can still ask for it with /S5, but UIDE will otherwise "prefer" 15-MB if
/H is given and it loads in HMA space. Note also that if a 15-MB cache
cannot fit in the HMA, UIDE will default to loading in upper/DOS memory.
"Not TOO bad!", as the memory needed for up to a 100-MB UIDE /P cache is
only about 7.5K! [Up to a 250-MB /P cache is only about 12K, as well!]

On your 32-MB Pentium system, unless you have other uses for XMS memory,
I would set at least UIDE's 15-MB cache, for better performance.

>> Real-mode UMBPCI users do not need UIDE /P. A protected-mode JEMM386
>> user can now choose between UIDE /P, for more speed using medium-size
>> caches, or UIDE without its /P switch when a larger cache is required.
>
> Slightly complex, but good to know. Thanks! ;-)
You are welcome! I know the rules for using UIDE /P are a bit complex,
but it is "about all I had LEFT" to give UIDE more protected-mode speed!
Japheth had to delete direct Int 15h "calls" (for XMS moves) from HIMEMX
same as I had to delete /K from UIDE, since neither worked with Win/311.
UIDE /P "buys back" some of that lost speed for JEMM386 users and others
who run DOS in protected-mode.

---
(Account disabled on user's request.)

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22632 Postings in 2109 Threads, 402 registered users, 366 users online (0 registered, 366 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum