From owner-freebsd-chat  Mon Nov 25 14:46:38 1996
Return-Path: owner-chat
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id OAA16617
          for chat-outgoing; Mon, 25 Nov 1996 14:46:38 -0800 (PST)
Received: from hill.gnu.ai.mit.edu (hill.gnu.ai.mit.edu [128.52.46.43])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA16551
          for <chat@FreeBSD.org>; Mon, 25 Nov 1996 14:45:50 -0800 (PST)
Received: by hill.gnu.ai.mit.edu (8.6.12/8.6.12GNU) id RAA10124; Mon, 25 Nov 1996 17:45:03 -0500
Date: Mon, 25 Nov 1996 17:45:03 -0500
Message-Id: <199611252245.RAA10124@hill.gnu.ai.mit.edu>
From: Joel Ray Holveck <joelh@gnu.ai.mit.edu>
To: msmith@atrad.adelaide.edu.au
CC: terry@lambert.org, grog@lemis.de, chat@FreeBSD.org,
        smut@clem-162.dorms.tamu.edu
In-reply-to: <199611242255.JAA25651@genesis.atrad.adelaide.edu.au> (message
	from Michael Smith on Mon, 25 Nov 1996 09:25:21 +1030 (CST))
Subject: Re: SCSI A/V drives
Sender: owner-chat@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk


   >    So, to deal with the "AV" crowd, whose hardware often can't handle
   >    being starved of data for several hundred ms, drive manufacturers made
   >    the recalibration process interruptible, so that data operations
   >    continue and recalibration occurs in the "background".
   > I thought that most SCSI devices released the bus during the entire
   > seek process, which was one of the advantages of SCSI over IDE to
   > begin with.  Am I mistaken?
   No, you're just missing the issue; if the drive is busy doing recal,
   it will accept your transactions, but it won't perform them until
   recal is finished - ie., your command's data returns very late.

Okay, understood... I hadn't realized that the recal was a
time-consuming process.  Why does the drive logic not continuously
update the thermal expansion factor it uses, each time it seeks?