Date: Tue, 2 Dec 2008 06:14:20 -0600 From: David Kelly <dkelly@hiwaay.net> To: Jan Mikkelsen <janm@transactionware.com> Cc: freebsd-stable@freebsd.org Subject: Re: 7.1-PRERELEASE: arcmsr write performance problem Message-ID: <34C71E28-F128-4F83-80EF-75768172A59D@hiwaay.net> In-Reply-To: <4934CB77.30906@transactionware.com> References: <2515BCEE3A2F4CBA8FFB9F1C052924AA@jmlaptop> <4934CB77.30906@transactionware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 1, 2008, at 11:45 PM, Jan Mikkelsen wrote: > Replying to my own post ... > > I have done a test on the same machine comparing 6.3-p1 to 7.1- > PRE. The performance is the expected ~6MB/s (because of the lack > of cache) on 6.3-p1, so the BIOS change doesn't seem to be at fault. > > This seems to be a regression somewhere between 6.3 to 7.1. The > Areca driver is the same in 6.3 and 7.1, so the problem seems to be > elsewhere. > > I think this is more than just a "performance" problem. The > observations with gstat showing extremely high ms/w values (I have > seen them as high as 22000) makes it look like IO completion > interrupts are being lost. > > Any suggestions on where to look next? Are there obvious candidates? ATA maximum block transfer has dropped from 128k to 64k in 7.x. Am not sure where the handle is to tweak it back up but has slowed peak thruput on my Dell PE400SC. Can watch with "systat -v" Worse, I have a stripped array of 2 drives that won't transfer more than 43k at a chunk because apparently the stripe metadata didn't align nicely on 64k multiples. -- David Kelly N4HHE, dkelly@HiWAAY.net ======================================================================== Whom computers would destroy, they must first drive mad.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34C71E28-F128-4F83-80EF-75768172A59D>