From owner-freebsd-hardware Sat Apr 13 20:07:51 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA16780 for hardware-outgoing; Sat, 13 Apr 1996 20:07:51 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id UAA16734 for ; Sat, 13 Apr 1996 20:07:08 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id NAA11913; Sun, 14 Apr 1996 13:05:41 +0930 From: Michael Smith Message-Id: <199604140335.NAA11913@genesis.atrad.adelaide.edu.au> Subject: Re: Micropolis 1991 AV 9GB Drive To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Sun, 14 Apr 1996 13:05:41 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, jacs@gnome.co.uk, hardware@FreeBSD.ORG In-Reply-To: <9603138294.AA829427555@ccgate.infoworld.com> from "Brett Glass" at Apr 13, 96 03:25:41 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Brett Glass stands accused of saying: > > > "Average access times" are a bit of a furphy. Look at the 'full stroke' > > timings for starters. > > "Full stroke" timings don't take cylinder capacity into account, and are > therefore not as good a metric. Huh? Given an aribtrary distribution of data across the disk (the norm for a reasonably populated filesystem), full-stroke timings are _very_ relevant. Just because you're traversing "more data" doesn't make said traversal any _faster_. > > J. Random Tower's PSU will have most of it's balls behind the 5V rail. > > Ratings are readily available, and show that most supplies are capable of > supplying the SPIN-UP current of the latest disks (far more than is needed > during actual use) continuously. Older disks might be a problem, but we're > talking about today's technology. I'm suggesting that the disks you were talking about, ie. the 1991 and the Seagate equivalent, have harsh spinup current requirements, and that the average PC supply isn't really up to it. I stand by that, based on considerable personal experience 8) > > It sounds like you're looking at them in the context of Multimedia > > applications, and under those circumstances these issues aren't so > > significant. For all the bulk data throughput, MM apps don't actually > > work the disk very hard. > > Just try playing back several movies at the same time and listen to the > thrashing! ... sit next to one during an expire run on a large news spool. Remember to bring a coffee or three. 8) > --Brett -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[