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 <macal...@netbsd.org>: > > 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