Re: HEADS-UP: SATA NCQ support merged (from jdolecek-ncq branch)

2017-10-12 Thread Thor Lancelot Simon
On Wed, Oct 11, 2017 at 07:56:04PM -, Michael van Elst wrote: > t...@panix.com (Thor Lancelot Simon) writes: > > >It probably has to do with our small maximum transfer size. The disk is > >probably trying to be safer and *not* caching tagged writes as aggressively, > >but with only 32

Re: HEADS-UP: SATA NCQ support merged (from jdolecek-ncq branch)

2017-10-11 Thread Chavdar Ivanov
It supports AHCI mode only on the regular internal disk, not on a disk connected via a tray to the CDROM. On Thu, 12 Oct 2017, 00:11 Michael van Elst, wrote: > On Wed, Oct 11, 2017 at 08:19:13PM +, Chavdar Ivanov wrote: > > I see you are on a ThinkPad as well. I have

Re: HEADS-UP: SATA NCQ support merged (from jdolecek-ncq branch)

2017-10-11 Thread Chavdar Ivanov
I see you are on a ThinkPad as well. I have mentioned it elsewhere, on my ThinkPad T61p I am getting reliably since the NCQ update the following: ... wd0 at atabus0 drive 0 wd0: wd0: drive supports 16-sector PIO transfers, LBA48 addressing wd0: 298 GB, 620181 cyl, 16 head, 63 sec, 512 bytes/sect

Re: HEADS-UP: SATA NCQ support merged (from jdolecek-ncq branch)

2017-10-11 Thread Michael van Elst
On Wed, Oct 11, 2017 at 08:19:13PM +, Chavdar Ivanov wrote: > I see you are on a ThinkPad as well. I have mentioned it elsewhere, on my > ThinkPad T61p I am getting reliably since the NCQ update the following: > ... > wd0 at atabus0 drive 0 > wd0: > wd0: drive supports 16-sector PIO

Re: HEADS-UP: SATA NCQ support merged (from jdolecek-ncq branch)

2017-10-11 Thread Michael van Elst
macal...@netbsd.org (Michael) writes: >/home/ml# sysctl -w hw.wd1.use_ncq=0 >hw.wd1.use_ncq: 1 -> 0 >/home/ml# dd if=/dev/rwd1c of=/dev/null bs=1m count=2048 >2048+0 records in >2048+0 records out >2147483648 bytes transferred in 21.747 secs (98748500 bytes/sec) Please try to use different

Re: HEADS-UP: SATA NCQ support merged (from jdolecek-ncq branch)

2017-10-11 Thread Michael van Elst
t...@panix.com (Thor Lancelot Simon) writes: >It probably has to do with our small maximum transfer size. The disk is >probably trying to be safer and *not* caching tagged writes as aggressively, >but with only 32 commands in-flight (SCSI/SAS allow 256) and a maximum >transfer size of 64K (our

Re: HEADS-UP: SATA NCQ support merged (from jdolecek-ncq branch)

2017-10-11 Thread Michael
Hello, On Tue, 10 Oct 2017 23:11:54 +0200 Jaromír Doleček wrote: > I've seen this on one of my disks, too. It seems it's much slower in NCQ > mode. I think the firmware might not utilise the disk cache properly when > in NCQ mode. > > You can try switching it off via

Re: HEADS-UP: SATA NCQ support merged (from jdolecek-ncq branch)

2017-10-10 Thread Thor Lancelot Simon
On Tue, Oct 10, 2017 at 11:11:54PM +0200, Jarom??r Dole??ek wrote: > I've fixed the compilation for ALL kernels. > > 2017-10-10 17:34 GMT+02:00 Michael : > > I tried sequential reads ( dd if=/dev/rwd0c ... ) and throughput took a > > significant hit. I used to get about

Re: HEADS-UP: SATA NCQ support merged (from jdolecek-ncq branch)

2017-10-10 Thread Jaromír Doleček
I've fixed the compilation for ALL kernels. 2017-10-10 17:34 GMT+02:00 Michael : > I tried sequential reads ( dd if=/dev/rwd0c ... ) and throughput took a > significant hit. I used to get about 120MB/s with the siisata, now it > fluctuates between 80 and 90MB/s, ahcisata

Re: HEADS-UP: SATA NCQ support merged (from jdolecek-ncq branch)

2017-10-10 Thread Michael
Hello, On Sat, 7 Oct 2017 18:34:04 +0200 Jaromír Doleček wrote: > I've merged the NCQ branch to HEAD. Nice, thanks! > The code was quite extensively tested on that harware on amd64. Other archs > and drivers compile, but I had no way to test them. Particularily, I