From owner-freebsd-hardware Wed Feb 19 20:03:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA14278 for hardware-outgoing; Wed, 19 Feb 1997 20:03:50 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA14264; Wed, 19 Feb 1997 20:03:23 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id OAA15277; Thu, 20 Feb 1997 14:30:51 +1030 (CST) From: Michael Smith Message-Id: <199702200400.OAA15277@genesis.atrad.adelaide.edu.au> Subject: Re: _big_ IDE disks? In-Reply-To: <199702200307.OAA16623@godzilla.zeta.org.au> from Bruce Evans at "Feb 20, 97 02:07:28 pm" To: bde@zeta.org.au (Bruce Evans) Date: Thu, 20 Feb 1997 14:30:49 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, se@freebsd.org, hardware@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-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bruce Evans stands accused of saying: > >> wdc0 at 0x1f0-0x1f7 irq 14 flags 0x80ff80ff on isa > >> wdc0: unit 0 (wd0): , 32-bit, multi-block-16 > >> wd0: 788MB (10003392 sectors), 9924 cyls, 16 heads, 63 S/T, 512 B/S > > >> -------Sequential Output-------- ---Sequential Input-- --Random-- > >> -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > >> Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU > >> 128 3858 71.8 8178 28.2 2486 14.1 4210 71.1 8280 28.1 117.0 4.7 > > > >Ok. Quite good performance for an (E)IDE drive ... > > I checked the specs for it. It really can do > 8MB/s except > possibly on the inner tracks. Yup, this was a basic criteria for it being used instead of a SCSI disk; by the time you compensate for the extra CPU overhead, I figured that it would make a reasonable alternative to a ~3M/sec SCSI disk (which was not available 8( ) > The 28% overhead for the block mode i/o's is probably mostly for copying > from the buffer cache. If the CPU is a P5/166, then i586-optimized > copyout is apparently not being used. I think the overhead would be > about 20% with it (I see 14% for 5MB/sec on a P5/133). How do I go about ascertaining this? npx0 is enabled, and the kernel was build with I586_CPU defined (obviously). The kernel it's running is built with npx.c v 1.31.2.5. > Bruce -- ]] 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 [[