From: 5916rahmank@vms.csd.mu.edu (Anisur Rahman)
Newsgroups: comp.os.ms-windows.setup
Subject: Re: Smartdrv vs Built-In Cache
Date: 25 Jul 92 22:08:52 GMT
Article-I.D.: vms.0095E1C5.3BDE0260
Reply-To: 5916rahmank@vms.csd.mu.edu
Organization: Marquette University - Computer Services

|From: ketil@edb.tih.no (Ketil Albertsen,TIH)
|Newsgroups: comp.os.ms-windows.setup
|Subject: Re: Smartdrv vs Built-In Cache
|Date: 22 Jul 92 12:14:27 GMT

|One thing is for certain: Do not run *both* a software controlled cache and
|a cache in the disk drive, hoping to get a double speedup! At least not
|when buffering writes: When the software cache decides to throw out a
|block because it is no longer being used, the drive cache will see this
|as activity on this block, putting it at highest priority in its LRU list.
|It may even have to throw out another, active block to make room for it,
|and if the disk allows writes of smaller blocks than the physical disk page
|or cache frame size, it may even have to read the page from disk (if it
|was thrown out due to passiveness - remember that activity on the block
|is invisible to the drive cache, it is hidden by the soft caching). Note
|that the number of disk accesses *increase* due to the double caching!
|
|With read caching only (write through), the major negative effect is the
|waste of resources - the drive cache holds the same data as the software
|cache, so the data is found in the software cache without reading the
|drive cache. Well, this is a simplification, in particular if the drive
|cache is much larger, but it gives the main idea. But it is easy to make
|examples where adding a software cache actually slows down: The more 
|frequently a block is read, the more likely the drive cache is to see it 
|as passive (because it remains in the software cache, which hides all the 
|accesses). If it is purged from the software cache due to temporary high
|activity in many other blocks, the drive cache is not informed; for a page 
|that is only read, there is no need to. Soon thereafter, the block is 
|needed again, but it is then not found in the drive cache but must be 
|read from disk. Removing the software cache lets the drive cache see all 
|accesses, and give the frequently used block a proper priority. Note, by 
|the way, that this anomaly essentially occurs when the drive cache is the 
|larger one - if they are the same size (or the drive cache smaller), the
|block will be out of the drive cache in any case.
|
 .... some discussion deleted ....

	While lots of (theoretical?) discussions on this topic are coming,
	I ran a small experiment. I measured the time required to load
	various programs to examine the effect of smartdrv.exe. Following
	table summerizes the results.

	Effect of smartdrv.exe on loading time of win 3.1 and other
	applications					
        ------------------------------------------------------------

		Smartdrv.exe loaded (w/double buffer)		Not loaded
                -------------------------------------		----------
1. Time to load win 3.1:		29:00 sec		36:27 sec

2. Time to load W4W 2.0a:		8:23 sec		12:46 sec

3. Time to load a 2.11MB file						
   in W4W. This file has						
   lots of graphics in it:		3:82 sec		4:10 sec
						
4. Time to save the same file:		16:17 sec		19:10 sec

5. Time to load excel 4.0:		8:29 sec		11:14 sec

The system used is:
	486DX2 running at 64MHz (with 256k external cache)
	16Meg RAM
	DTC SCSI (EISA) controller with 512K on board cache
	Maxtor 333MB Hard drive with cache 
	Diamond SpeedSTAR w/1MB VRAM.

	This experiment shows that when smartdrv.exe is loaded it saves time 
i.e., the system performs much better than when it is not loaded. This 
difference in time (which translates to the performance of the system) becomes
more prominent with systems with lower clock speed. However, the main question
here is smartdrv vs. built in cache. It would be interesting to perform similar
time measurements on other systems and then make a comparison. But still the
question remains: why smartdrv enhances performance even though there is
built-in cache on the drive (as well as on the controller)? 
	With regards,
			Anis Rahman
			Dept. of EECE
			Marquette University
			5916rahmank@vms.csd.mu.edu
			(414) 223-3152