Difference between 6.2 and 7.0 Adaptec 39320D - 7.0 performing
scottl at samsco.org
Tue Apr 17 15:30:11 UTC 2007
Kris Kennaway wrote:
> On Tue, Apr 17, 2007 at 01:12:06PM +0200, Gelsema, P (Patrick) - FreeBSD wrote:
>> On Tue, April 17, 2007 01:03, Kris Kennaway wrote:
>>> On Mon, Apr 16, 2007 at 10:47:24PM +0200, Gelsema, P (Patrick) wrote:
>>>> Goodevening lists,
>>>> I am toying with Freebsd 7 to see if it will and how it runs on my new
>>>> M2N mainboard. One of the things I noticed is that when running
>>>> 7.0-Current-200704 the throughput of the SCSI drive seems halved. When
>>>> running 6.2 throughput is doubled/normal.
>>>> Throughput is measured with the following command.
>>>> dd if=/dev/zero of=/usr/test
>>>> where /usr resides on da0s1f
>>>> On 7.0 I get about 33MB/sec
>>>> On 6.2 I get about 69Mb/sec
>>>> I did not make any changes, installation is fresh from CD with Minimal
>>> Apparently you weren't paying attention during boot, because 7.0 ships
>>> with heavy debugging options enabled, and tells you about it up front:
>>> "WARNING: WITNESS option enabled, expect reduced performance.\n";
>>> Recompile your kernel with debugging options disabled before making
>>> performance comparisons.
>> Ok, what you are saying makes sense. I did see the warnings and the bits
>> in the kernel config. The thing that triggered me was that when paying
>> attention during boot the SCSI Disk was detected as only 160.00MB/s
>> instead of the expected 320.00MB/s. The detection of devices is not
>> subject to debugging, is it?
> Someone else pointed this out to me, to be honest I didn't get that
> far in your email after noticing the big blunder of leaving debugging
> enabled :)
> I agree that the different speed negotiation is a likely potential
> cause of poor performance as well, but it really doesn't make sense to
> be making performance comparisons when one system has all possible
> debugging enabled and the other has no debugging enabled.
The difference in bus speed is hardly perceptible for a single target.
U320 does reduce the per-command latency by a good deal, but for large
I/O transfers it'll mostly be in the noise.
More information about the freebsd-current