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

[Thor Lancelot Simon <tls%panix.com@localhost>]

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 <macallan%netbsd.org@localhost>:
> > 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 dropped from about 80MB/s to
> > 70MB/s. Both spinning rust of varying vintage.
> > I should probably do a bonnie run on either one before & after to see
> > if there's any change in random access.
> 
> 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.

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 MAXPHYS), that's only 2MB of in-flight data;
maybe not enough to keep up with the actual bandwidth of the media at
its real latency.

Most other operating systems will hand the drive 32 x 128K transfers, or
even larger.  If you want to attack the -- fairly minor at this point,
I think -- problems of rebasing and merging the tls-maxphys branch,
I bet it would help here.

I have the interest, but not the time, I'm afraid.  Real life interferes
again.

Thor