From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 13:53:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C5C21065674; Fri, 3 Jul 2009 13:53:27 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id C4AC58FC18; Fri, 3 Jul 2009 13:53:26 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPA id 247581945; Fri, 03 Jul 2009 16:53:21 +0300 Message-ID: <4A4E0D51.3080904@FreeBSD.org> Date: Fri, 03 Jul 2009 16:53:21 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: Mike Tancsa References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> In-Reply-To: <200907031326.n63DQCGM016627@lava.sentex.ca> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , scottl@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 13:53:27 -0000 Mike Tancsa wrote: > At 05:20 PM 7/2/2009, Mike Tancsa wrote: >> But, going back to the original i386 image, with the boot blocks >> reinstalled and using your latest patch, it seems to work! (however, >> the same 300sec delay due to the cdrom ? ) > > At first, I thought something was a miss speed wise, but it looks like > this hardware is either having issues, or something is wrong in general > as its the same no matter which driver is used. Usually the speeds are > much quicker than whats below on block writes > > > Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done... > -------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 > 1 4000 39798 20.8 39725 4.3 17776 3.4 40269 27.1 42085 4.2 > 255.8 0.6 > 2 4000 38827 20.3 40116 4.4 18068 3.4 40227 27.3 42266 4.3 > 244.8 0.5 > 3 4000 39748 20.8 40166 4.4 17952 3.3 40192 27.3 42259 4.3 > 243.4 0.5 > 4 4000 39855 20.8 40066 4.4 18017 3.3 40206 27.1 42401 4.2 > 264.2 0.6 > > 1=AHCI in bios, AHCI.ko loaded > 2=AHCI in bios, plain old ata driver used post patch > 3=IDE in bios, plain old ata driver used post patch > 4=IDE in bios, plain old ata driver from the cvs This test looks inadequate. there is almost no modern SATA HDDs having only 40MB/s of linear read/write speed. Usual values now are 60-100MB/s and they should be reached with almost any working driver. Can you try simple `dd if=/dev/ada0 of=/dev/null bs=1m count=1000`? To obtain any measurable benefit from NCQ usage you should have many random requests to the drive running simultaneously. Not sure how this specific test works. Also NCQ depends on effective disk firmware to realize that benefit. > Note, with 2 dmesg shows > acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 > acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 > > the boot process then hangs for about 5 seconds, and then proceeds > > with 3, the boot process hangs a total of about 2 min. If you have issues with old driver also, then it is probably some drive specifics, but not a bug of the new implementation. There was no changes to the old ATA. -- Alexander Motin