[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RamFAST & GS/OS cache
fmlin@terapin.com (Frank M. Lin) writes:
>It really shows with the CD-ROM drive. I mean, since the drive's access time
>is slow, I can tell that lot of the time is spent on reading the directory.
>After the directory is read, it looses it pretty fast... if I close like 2 or
>3 folders, and then try to go back, it would be re-reading it.
This may be because CD-ROM's have a vastly different directory structure than
what you'd expect. They are designed to make searching for one file on a HUGE
directory tree as fast as possible given the technology. Unfortunately the
method they end up with isn't too friendly for directory listings. If you have
a Rev D then upping the cache to 1 meg will probably fix it, but I haven't
actually tried this (don't even have a CD-ROM), so get a second opinion
(preferably from somebody who's got 1 meg) before you plunk down the cash.
>1. How smart is the GS/OS cache?? Does it know when to flush the cache if the
>directory information has been changed?
The GS/OS cache is not used by the RAMfast driver. The RF's point of view is
that it's faster to DMA stuff into memory wherever the GS wants it rather than
spend time letting GS/OS look around trying to remember where it cached a block
-- the GS/OS cache works great for slow devices but not for fast ones.
>3. Do all 16 bit programs benefit from GS/OS cache? Do certain toolsets have
>to be started by the application?
Nope. It's built into GS/OS and is always there when 16 bit stuff is running.
Todd Whitesel
toddpw @ cco.caltech.edu