Date: Tue, 26 Nov 1996 14:15:12 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: terry@lambert.org (Terry Lambert) Cc: chat@freebsd.org Subject: Re: A/V drives Message-ID: <199611260345.OAA01178@genesis.atrad.adelaide.edu.au> In-Reply-To: <199611260312.UAA23966@phaeton.artisoft.com> from Terry Lambert at "Nov 25, 96 08:12:38 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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 [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611260345.OAA01178>