DOS ain't dead

DMA v.s. Caching -- BOTH Are Important! (Announce)

posted by Jack , Fresno, California USA, 05.11.2009, 19:07

> Thanks for update!

You are welcome! This update was difficult, VERY frustrating and it took
me 5 days to get a proper solution. But, nice results -- UIDE speed has
improved, and I did NOT need my "emergency plan", which was to put UIDE's
search tables back into normal memory! UIDE still takes only 4864 bytes
of upper-memory, or 992 plus 3824 bytes of HMA space, for any size cache!

> In this opportunity I would like to ask what is now the more important
> part of speed benefit what UIDE gives. It is the caching or the DMA
> transfers? From your changelog it seems like DMA is more or less
> obsolete. Or am I wrong?

Both DMA and caching are important, but in different ways.

I tried UIDE with caching but with my hard-disk run by my BIOS, and I set
the BIOS "VDS services" flag, so the BIOS would not use DMA. 32 seconds
to copy my big WINNT\SYSTEM32 directory, v.s. 5 seconds when UIDE handles
the disk using its own DMA routines.

If I use UIDEJR, i.e. DMA but no caching, copying my WINNT\SYSTEM32 files
takes 13 seconds, v.s. 5 seconds as above.

My conclusion: If one does much file copying, DMA is more important, but
if one does much "repetitive" reading of the same files (compilers, data-
bases, etc.) caching shall obviously become more important.

As I note in the drivers' README file, the best plan is to load RDISK and
put heavily-used files in RAMdisk memory, then load UIDE and let it cache
"ordinary" data files. RDISK uses 752 upper-memory bytes, UIDE uses the
memory noted above, plus the XMS memory needed for both drivers. Rather
a "cheap price", for their HUGE improvement in DOS performance!

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

Complete thread:

• New 11-04-2009 UIDE Available. - Jack, 05.11.2009, 13:48 (Announce)
  • New 11-04-2009 UIDE Available. - Laaca, 05.11.2009, 17:41
    • DMA v.s. Caching -- BOTH Are Important! - Jack, 05.11.2009, 19:07
  • New 11-04-2009 UIDE Available. - DOS386, 06.11.2009, 05:33