From owner-freebsd-chat Mon Nov 25 19:47:44 1996 Return-Path: owner-chat Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA04179 for chat-outgoing; Mon, 25 Nov 1996 19:47:44 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA04148 for ; Mon, 25 Nov 1996 19:47:11 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id OAA01178; Tue, 26 Nov 1996 14:15:12 +1030 (CST) From: Michael Smith Message-Id: <199611260345.OAA01178@genesis.atrad.adelaide.edu.au> Subject: Re: A/V drives In-Reply-To: <199611260312.UAA23966@phaeton.artisoft.com> from Terry Lambert at "Nov 25, 96 08:12:38 pm" To: terry@lambert.org (Terry Lambert) Date: Tue, 26 Nov 1996 14:15:12 +1030 (CST) Cc: chat@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-chat@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert stands accused of saying: > > But you're still failing to accept the basic point; A/V drives _do_ > > perform thermal recal, as it is essential to maintaining drive > > performance. However, the recal process can be preempted by incoming > > data transactions. > > So is it being done while it has been preempted? Or does preempted > have some new meaning I'm unfamiliar with? Ok, let's step back a sec : conventional drive : recal is atomic operation, transactions postponed until recal complete. "A/V" drive : recal is interruptible operation, can be suspended to allow transactions to complete. If an A/V drive is doing a recal when a transaction arrives, it saves the recal context, processes the transaction, and then returns to the recal. In most cases, even with back-to-back transactions coming in on the interface, the servo will have enough idle time to keep up with recal. Naturally the scheduling algorithm is designed to ensure that the recal process gets _some_ time even if the drive is saturated. > (potentially using the guard tracks to do so). And I know that > increased head hysteresis will shorten the average time to failure, > as the AV drive, having preempted its recal, may end up being a bit > more off than a drive that completed recal without preemption. I haven't seen or inferred any evidence that suggests that small additional amounts of head traversal significantly affect MTBF; if this is your only point, why not make that? > No. One of my major claims was that they had better performance for > streaming data (if you read the start of this thread at all), and that > they made some tradeoffs to get it. I personally consider some of the > tradeoffs to be "iffy". I'm aware of this, however the tradeoffs that you described were _not_ the tradeoffs being made, and I'm inclined not to accept the conclusions that you're drawing from your claims. My only real gripe was you spreading misinformation 8) > > Stick to filesystems. > > Natch. And place them on drives... How many drivers on the road understand automatic transmissions? > Terry Lambert -- ]] 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 [[