Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!usc!apple!agate!shelby!decwrl!shlump.nac.dec.com!mountn.dec.com!minow
From: minow@mountn.dec.com (Martin Minow)
Newsgroups: comp.sys.mac
Subject: Re: Comparing performance of Quantum and Imprimis hard disks
Summary: Quantum's Disk Caching
Keywords: Imprimis Quantum hard disk
Message-ID: <924@mountn.dec.com>
Date: 6 Oct 89 13:51:27 GMT
References: <9009@batcomputer.tn.cornell.edu>
Reply-To: minow@mountn.enet.dec.com (Martin Minow)
Organization: Digital Equipment Corporation
Lines: 32

In article <9009@batcomputer.tn.cornell.edu> eacj@tcgould.tn.cornell.edu
(Julian Vrieslander) writes:
>In an earlier posting, someone claimed that the Quantums do not have
>caching.  But the SuperMac and GCC brochures say that these devices have
>64k look-ahead caches.  How does such a cache work?  And why would Imprimis
>disable it for their throughput test?

Quantum Q200 series disks have a DisCache (TM) that contains an on-drive
60K byte look-ahead disk cache.  (The Q200 series is 5.25; I assume that
the 3.5 inch drives are firmware-compatible; the cache size may have
changed, however.)  This is controlled by a Quantum-unique "page" in the
Mode Select command.  The page gives the user the ability to turn caching
on and off, set the size of the cache table, and specify prefetch threshold
and limits.  (Prefetch causes the drive to read sector N+1, N+2, etc. into
the cache when the application asks for sector N.  The Quantum documentation
(mine dates from 1987, so it's probably out of date) states that both
read and write operations are cached.  It's not clear, however, whether
the Quantum returns "command complete" before data being written is
actually on the disk platter; I suspect not.

Judging from advertising, I suspect that the cache is responsible for
changing the 19 msec average access time into 12 msec effective access time.

Note that the effectiveness of a cache depends on the application.  A
random-sector disk test program will not make as effective use of a cache
as a real application.  I can't see any reason for turning it off in
a real-world Macintosh application; expecially given the overhead of
the Macintosh I/O system itself.

Martin Minow
minow@thundr.enet.dec.com
The above does not represent the position of Digital Equipment Corporation