From owner-freebsd-current@FreeBSD.ORG Sun Jun 20 19:27:48 2010 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 8F0D81065670 for ; Sun, 20 Jun 2010 19:27:48 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 2AAEE8FC14 for ; Sun, 20 Jun 2010 19:27:47 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id o5KJRhaf011687; Sun, 20 Jun 2010 13:27:43 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: Date: Sun, 20 Jun 2010 13:27:43 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <63849665-E1D3-417F-B6BD-5601E5361315@samsco.org> References: <4C1AB4C0.4020604@freemail.hu> <4C1B3792.9000007@freemail.hu> <4C1C0ED9.8090103@freemail.hu> <2F904ED8-BC95-459F-8536-A889ADDA8D31@samsco.org> <4C1E4722.3050506@freemail.hu> To: Artem Belevich X-Mailer: Apple Mail (2.1078) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: oizs , freebsd-current@freebsd.org Subject: Re: Dell Perc 5/i Performance issues 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: Sun, 20 Jun 2010 19:27:48 -0000 Yeah, there's no value in using the /dev/random devices for testing disk = i/o. Use /dev/zero instead. I've known of hardware RAID engines in the = past that can recognize certain repeating i/o benchmark patterns and = optimize for them, but I have no idea if LSI controllers do this, tho = based on your results it's probably safe to say that they don't. Scott On Jun 20, 2010, at 1:09 PM, Artem Belevich wrote: > /dev/random and /dev/urandom are relatively slow and are not suitable > as the source of data for testing modern hard drives' sequential > throughput. >=20 > On my 3GHz dual-core amd63 box both /dev/random and /dev/urandom max > out at ~80MB/s while consuming 100% CPU time on one of the processor > cores. > That would not be enough to saturate single disk with sequential = writes. >=20 > --Artem >=20 >=20 >=20 > On Sun, Jun 20, 2010 at 9:51 AM, oizs wrote: >> I've tried almost everything now. >> The battery is probably fine: >> mfiutil show battery >> mfi0: Battery State: >> Manufacture Date: 7/25/2009 >> Serial Number: 3716 >> Manufacturer: SMP-PA1.9 >> Model: DLFR463 >> Chemistry: LION >> Design Capacity: 1800 mAh >> Design Voltage: 3700 mV >> Current Charge: 99% >>=20 >> My results: >> Settings: >> Raid5: >> Stripe: 64k >> mfiutil cache 0 >> mfi0 volume mfid0 cache settings: >> I/O caching: writes >> write caching: write-back >> read ahead: none >> drive write cache: default >> Raid0: >> Stripe: 64k >> mfiutil cache 0 >> mfi0 volume mfid0 cache settings: >> I/O caching: writes >> write caching: write-back >> read ahead: none >> drive write cache: default >>=20 >> Tried to play around with this as well, with almost no difference. >>=20 >> Raid5 >> read: >> dd if=3D/dev/mfid0 of=3D/dev/null bs=3D10M >> 1143+0 records in >> 1143+0 records out >> 11985223680 bytes transferred in 139.104134 secs (86160083 bytes/sec) >> write: >> dd if=3D/dev/random of=3D/dev/mfid0 bs=3D64K >> 22747+0 records in >> 22747+0 records out >> 1490747392 bytes transferred in 23.921103 secs (62319342 bytes/sec) >>=20 >> Raid0 >> read: >> dd if=3D/dev/mfid0 of=3D/dev/null bs=3D64K >> 92470+0 records in >> 92470+0 records out >> 6060113920 bytes transferred in 47.926007 secs (126447294 bytes/sec) >> write: >> dd if=3D/dev/random of=3D/dev/mfid0 bs=3D64K >> 16441+0 records in >> 16441+0 records out >> 1077477376 bytes transferred in 17.232486 secs (62525939 bytes/sec) >>=20 >> I'm writing directly to the device so im not sure any slice issues = could >> cause the problems. >>=20 >> -zsozso >> On 2010.06.20. 4:53, Scott Long wrote: >>>=20 >>> Two big things can affect RAID-5 performance: >>>=20 >>> 1. Battery backup. If you don't have a working battery attached to = the >>> card, it will turn off the write-back cache, no matter what you do. = Check >>> this. If you're unsure, use the mfiutil tool that I added to = FreeBSD a few >>> months ago and send me the output. >>>=20 >>> 2. Partition alignment. If you're using classic MBR slices, = everything >>> gets misaligned by 63 sectors, making it impossible for the = controller to >>> optimize both reads and writes. If the array is used for secondary = storage, >>> simply don't use an MBR scheme. If it's used for primary storage, = try using >>> GPT instead and setting up your partitions so that they are aligned = to large >>> power-of-2 boundaries. >>>=20 >>> Scott >>>=20 >>> On Jun 18, 2010, at 6:27 PM, oizs wrote >>>=20 >>=20 >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" >>=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org"