> I knew this would provoke a comment from you, Jack.
Yes, you always were a "provoker", weren't you, Bret?
> The purpose of a cache is to put as much data in RAM as it can, so that
> the disk is accessed as little as possible. It's true that the cached
> data does eventually get written to disk, and that part is slow. From a
> speed perspective, though, a well-designed cache can be competitive with
> a RAM disk.
Exactly why I designed UIDE to have all the features I noted before, along
with using only 944 bytes of memory (and some HMA which nothing but MS-DOS
HIMEM ever used before) and using XMS for its cache tables and cache data.
Try to find any "Write Back" caches that do so much, for so little memory!
> The advantage of a write-delay cache is that that the writing can be
> done when the system is "idle" (a simple form of multi-tasking). The
> end result is that even though disk writes actually take the same amount
> of time they always did, the SYSTEM actually runs much faster. In my
> experience and opinion (and it is only an opinion), write-through caches
> don't provide enough speed benefit to be very helpful, and I don't use
Well, we remain on different sides of a fence! I say "Write Through"
caches provide a LOT of benefit, especially UIDE which can cache up to
4-GB of data! Assuming only 2.5 or 3-GB is assigned to UIDE, one can
have 500-MB+ for a nice RAM disk like my RDISK offers, and so one gets
"The best of both worlds": A (big!) RAM disk for "fast" files, plus a
(big!) cache for "ordinary" disk files. UIDE/RDISK handle GIGABYTES,
not KB or MB like too many other never-upgraded "RAM disk" and "Write-
Back" cache programs! You can KEEP all those "old guys", and I shall
continue to do the BEST possible in UIDE/RDISK, for a LOT less memory!
>> There is a REASON why "Write Back" caches are all so large -- they
>> demand MANY "hooks" of a non-generic type into a DOS system ...
> Yes, write-delay caches are MUCH more complicated than write-through
> caches. But, they also provide MUCH more practical benefit, IMO ...
How I just DETEST "Internet" abbreviations, which are always such LAZY
and/or BAD English! But "FYB", "IMO" it is rather IMPRACTICAL to use
so much system memory in SMARTDRV/NCACHE2/etc. DOS is in fact memory
limited, and if I can have 90% the benefit of most "Write Back" caches
for 90% LESS memory by using UIDE, THAT seems a little more PRACTICAL!
> Even with that being said, I don't use SMARTDRV all the time. I only
> use it in certain situations when it provides noticeable benefit, and
> in those particular situations a write-through cache doesn't help.
Why not just use UIDE all the time? You would get UltraDMA I-O rather
than whatever your BIOS currently does, and I bet your NET system speed
would be greater, from having SOME type of cache "active" at all times!
> Also, FWIW, you can disable write-delay caching in SMARTDRV if you want,
> in which case it works sort of like UIDE or LBACACHE (except that it
> will also _natively_ work with non-INT 13h disks like USB and SCSI), but
> at the expense of requiring more memory.
SCSI disks are rarely seen on PCs, due to their high disk and controller
cost. USB disks are also rarely seen, since they are not-yet reliable,
nor in many cases are they fast-enough to replace hard disks. SATA/IDE
"own" the hard-disk market and probably will for a LONG time. So, I am
not-at-all "bothered" by UIDE handling only Int 13h disks, especially as
it still CAN be called by other drivers to cache THEIR disks, as well!
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
Freedos-user mailing list