From: ketil@edb.tih.no (Ketil Albertsen,TIH)
Subject: Re: Smartdrv vs Built-In Cache
Organization: T I H / T I S I P 
Posting-Front-End: Winix Conference v 92.05.15  1.20 (running under MS-Windows)
Date: Wed, 22 Jul 1992 21:08:49 GMT

In article <1992Jul22.144943.1814@bronze.ucs.indiana.edu>, cdent@europa (Christopher Dent) writes:

>[...]
>Hard Disk Controller with 16Mb cache (just testing it out had some ram lying  
>about) that is set in its BIOS to be "optimized for windows"
>When windows installed itself it set smartdrv to double buffering (drive
>is IDE not scsi).
>
>What should I do to have maximum performance?
>Would it be best to take some ram off the hd controller? Or leave it
>packed and remove smartdrv? Leave it as it is? Try a different software
>cache?

The effect of caching always depends on access patterns (and therefore on
your program mix), so there is no single correct answer. If you have some 
idea of the type of program mix, try it out and see! But unless you
have another computer simulating a human (or more, if you have a multiuser
machine - but with Windows that is less likely!), it is difficult to
provide exactly the same load for each configuation.

Yet, I dare to make an educated guess that the best thing would be to
remove smartdrv. As long as there is plenty of main memory in the PC it
will not slow down, but not speed up, either. So you loose a couple of Mb
of RAM with no positive effect - freeing it means that paging does not set
in until the load gets higher.

I would be surprised if a different software cache would be any different.

16 Mb controller cache sounds like a lot - I would think that the performance
increase from, say, 8 Mb cache would be unnoticable in a single-user system.
Will a single user really have enough things running to keep 16 Mb of
data (beyond what fits in primary memory) busy? If you have an option to
move 8 Mb from the controller to system ram, paging occurs 8 Mb later. And
even though the controller cache is magnitudes faster than a disk access,
a memory access without a page fault is magnitudes faster than a page fault
even if data is present in cache. 

If you will be accessing enormous amounts of *file* data, you may keep the
controller cache large. But remember that we are talking about *repeated*
access to file data - the first access to file data saves nothing from
the caching. After all, few applications read the same file data again and
again - they read it to a memory buffer, manipulate it there, and may write
it back afterwards. Better make sure that there is enough room for that
memory buffer, then, by moving ram to primary memory.

About Windows installing smartdrv with double buffering: Doesn't it always?
Give the command 'smartdrv' to obtain a table of disks handled by smartdrv. 
If the last column, labeled 'buffering', says 'no' for all drives, remove 
the smartdrv line in config.sys. MS documentation states explicitly that 
IDE drives need no double buffering. I think this will speed up slightly.

Also, to speed up disk accesses, you should enable the "32 bit disk access"
if that appears in your ControlPanel 386Enhanced VirtualMemory dialog. If
it doesn't, it is because you cannot use it with your disk, but I read the
MS doc to indicate that it will is available for IDE disks. (It is not for
my SCSI disk.) Windows will then use its own optimized routines, running
from fast RAM, rather than general/slower BIOS routines running in slow ROM.

By the way, when I bought my machine, it was set up to shadow ROM routines
to RAM. Except that they had forgotten to indicate *which* ROM areas to
shadow. When I corrected that, the speed of BIOS calls tripled. (The BIOS
of my machine can set up shadowing of 2*64 Kb ROM, but software versions
can do the same thing, and usually in a more flexible manner.) If you
haven't shadowed yet, do!

Also, on my previous machine, the disk was formatted with a non-optimal
interleave factor. Re-interleaving the disk significantly improved disk IO.
(I used SpinRite, but I think there are alternatives as well.)

I assume that you have been through all the optimizing hints in the Windows
doc: Defragment harddisk regularily, use a permanent swap file, turn off
filesyschange in system.ini etc. etc.

For performance in other areas: The speed of display drivers (for the same
hardware) varies with a factor of at least 10! Unfortunately, almost
all are good on some operations, bad on others - few are consistently good.
But those SVGA drivers delivered with Win 3.1 are more consistently
acceptable than those in 3.0, which were terrible in some respects! 
I think there are even better ones on the commercial market, though.

And don't use 256 color drivers or higher resolution than 600*800 unless 
you have to, if you want max speed. But well, with your local bus video
this may be far less of a concern than on cheaper machines.

Newsgroups: comp.os.ms-windows.setup