From owner-freebsd-stable@FreeBSD.ORG Mon Aug 16 15:33:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE84D1065674 for ; Mon, 16 Aug 2010 15:33:18 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id C1A568FC16 for ; Mon, 16 Aug 2010 15:33:18 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta04.emeryville.ca.mail.comcast.net with comcast id v0kj1e00C1eYJf8A43ZJYZ; Mon, 16 Aug 2010 15:33:18 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta19.emeryville.ca.mail.comcast.net with comcast id v3ZH1e0023LrwQ2013ZHgC; Mon, 16 Aug 2010 15:33:17 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id ABCD89B425; Mon, 16 Aug 2010 08:33:16 -0700 (PDT) Date: Mon, 16 Aug 2010 08:33:16 -0700 From: Jeremy Chadwick To: Kevin Oberman Message-ID: <20100816153316.GA58985@icarus.home.lan> References: <20100816144638.4ACF81CC3A@ptavv.es.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100816144638.4ACF81CC3A@ptavv.es.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, Ivan Voras Subject: Re: Inconsistent IO performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 15:33:19 -0000 On Mon, Aug 16, 2010 at 07:46:38AM -0700, Kevin Oberman wrote: > > From: Ivan Voras > > Date: Mon, 16 Aug 2010 15:03:23 +0200 > > Sender: owner-freebsd-stable@freebsd.org > > > > On 13.8.2010 18:01, Kevin Oberman wrote: > > > For some time I have seen very odd issues with IO performance on > > > 8-Stable. Going back to November of last year when 8.0 was released, I > > > see variations of up to 22% in identical operations. This is not a > > > degradation as the performance moves up and down. > > > > In 8.0-8.1 span of time there was some work on the ata driver to make it > > use MAXPHYS (128 KiB) transfer sizes instead of 64 KiB. Modifying this > > will involve changing and recompiling the kernel but if you want to try > > something and the hardware is SATA you might try the new AHCI driver > > ("ada"). > > > > http://ivoras.net/blog/tree/2009-11-17.trying-ahci-in-8.0.html > > Thanks. I appreciate the suggestion. I am running a 8-Stable kernel > from August 9, so I think I should be OK on this. IS there a requirement > to set some parameter in the kernel config to take advantage of this? > > While the ThinkPad has a SATA ICH6-M chip-set, it does not provide or any > SATA connections. Both SATA ports a run to a SATA/PATA converter chip > and the only 2 physical connections available are PATA. I am assuming > that this is because 2.5 in. SATA drives were pretty much unavailable > when this system was shipped. This was the last of the T43 series and > was dropped from the product line by Lenovo about a month after I got > it, to be replaced by T60 systems running Core2 chips and using SATA > drives. > > Just lousy timing almost 4 years ago. I should expand on what Kevin's stated (I read what was written 3 or 4 times over and it didn't jive; "if there's no physical SATA connections, why is a SATA/PATA converter in use?"). The T43 is a bizarre beast. The ICH6-M chipset uses SATA, but is physically wired to a custom PCB/adapter that serves a couple different purposes: - Converts a 2.5" PATA hard disk connector into SATA (meaning, the laptop actually uses 2.5" PATA hard disks). thinkwiki.org refers to this as a "SATA-to-PATA bridge" (controller-to-disk), while I tend to look at it as a PATA-to-SATA bridge (disk-to-controller). - Integrates a "middle-man" ASIC that supposedly intercepts ATA commands, in addition to doing some drive model string verification (requiring folks to purchase IBM-sanctioned drives). - The system BIOS knows of the PCB/adapter and, somehow, queries it to verifies its existence. I imagine it sends some vendor-centric ATA commands which the ASIC intercepts. Supposedly people have tried removing (desoldering) the adapter in attempt to use standard SATA disks and destroyed their systems in the process. As Kevin stated, the ICH6-M doesn't support AHCI, so using ahci.ko isn't an option in his case. It's possible that the adapter in question is going/has gone bad, is doing something awful, or the underlying drive itself has degraded in some way which SMART doesn't see (ex. on-disk cache going bad; wouldn't surprise me in this case). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |