On Sat, 2 Feb 2013 01:19:50 +0100 (CET) Wojciech Puchar <woj...@wojtek.tensor.gdynia.pl> wrote:
> > Investigating a bit more a device reset will also trigger the > > change so after changing the value you can use camcontrol reset > > to trigger the change to apply using e.g. > > camcontrol reset 0:0:0 > > THIS actually work. > > And the results are disastrous. in spite of NCQ working and fully filled, > when unpacking source tree (as a test) onto UFS filesystem gstat shows at > most 100 IOPS, and average 700 with write cache disabled. > > this is on / partition that spans 1/10 of disk. Drive can actually manage > multiple writes in short distance well with write cache enabled. > I also noticed a drastic drop in throughput when I disabled the write cache, about a factor of 4 or 5. However, in my case every HDD supports NCQ (32 tags), but NCQ is not enabled on any HDD. Whether that's because the driver for my chipset (ATI IXP700 AHCI SATA controller) doesn't turn NCQ on or for another reason, I can't say. I looked at the man page for camcontrol but a mechanism to turn on NCQ in the HDDs didn't jump off the page. Does anyone know off-hand of a way to turn on NCQ in the HDDs, other than maybe modifying the driver? -- Gary Jennejohn _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
