[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: HEADS-UP: SATA NCQ support merged (from jdolecek-ncq branch)
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
Main Index |
Thread Index |