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 >>>> Asus >>>> 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 >>>> as >>>> distribution. >>> 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. >>> >>> Kris >>> >> 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. > > Kris 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. ScottReceived on Tue Apr 17 2007 - 13:30:10 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:08 UTC