Date: Mon, 25 Nov 1996 09:25:21 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: joelh@gnu.ai.mit.edu (Joel Ray Holveck) Cc: msmith@atrad.adelaide.edu.au, terry@lambert.org, grog@lemis.de, chat@FreeBSD.org, smut@clem-162.dorms.tamu.edu Subject: SCSI A/V drives Message-ID: <199611242255.JAA25651@genesis.atrad.adelaide.edu.au> In-Reply-To: <199611241906.OAA06789@hill.gnu.ai.mit.edu> from Joel Ray Holveck at "Nov 24, 96 02:06:44 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Joel Ray Holveck stands accused of saying: > > 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. If the drive is the source/destination of your A/V stream, then starvation/overrun is likely. By performing recal in the background, the drive's response is more-or-less as normal. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611242255.JAA25651>