On Mon, 7 Jan 2019 at 08:46, Hannes Reinecke <hare@xxxxxxx> wrote: > > On 1/7/19 8:41 AM, Sitsofe Wheeler wrote: > > On Mon, 7 Jan 2019 at 07:17, Hannes Reinecke <hare@xxxxxxx> wrote: > >> > >> On 1/4/19 8:33 AM, Sitsofe Wheeler wrote: > >>> Blimey Laurence - you're really pushing the boat out on this one! > >>> > >> [ .. ] > >>> I've yet to attach the disk directly to the mobo. It's a bit fiddly as > >>> the most accessible port is meant for the DVD drive and I think it's > >>> speed is slower than the others. > >>> > >>> The speed of the ATA ports is lower than you might expect (this > >>> machine is fairly old): > >>> > >> [ .. ] > >>> [ 3.242623] ata2.00: FORCE: horkage modified (noncq) > >>> [ 3.242683] ata2.00: supports DRM functions and may not be fully accessible > >>> [ 3.242686] ata2.00: ATA-11: Samsung SSD 860 EVO 500GB, RVT01B6Q, > >>> max UDMA/133 > >>> [ 3.242689] ata2.00: 976773168 sectors, multi 1: LBA48 NCQ (not used) > >>> [ 3.245518] ata2.00: supports DRM functions and may not be fully accessible > >>> [ 3.247611] ata2.00: configured for UDMA/133 > >> > >> 'slower' is an understatement. > > > > Are you surprised that there would be such a dramatic difference in > > the speeds between the two SSDs (Samsung 860 EVO, Crucial MX500) on > > that particular workload in that same machine? > > > Not at all. Fair enough :-) My understanding is that both SSDs (when unloaded and mostly empty etc) would be far faster than what this particular machine could do but I stand corrected. > >> That adapter can't do NCQ, hence 'WRITE FPDMA QUEUED' (which _is_ an NCQ > >> command) will never be issued. > >> So I'd be _very_ surprised if you still see this problem there ... > > > > I'm curious, why would using the libata.force=2.00:noncq kernel > > command line (only mentioned in my very first mail) make using that > > drive more stable if the adapter could never accept that command > > anyway? Shouldn't the sending of that command have been disabled if > > anything along the way can't actually accept it? > > > 'WRITE FPDMA QUEUED' will ever be issued if the drive _and_ adapter can > do NCQ. As this is the offending command it's not surprising that > switching off NCQ (and hence the use of that command) will make the > machine more stable. > > Although I'd be curious about the 'more' bit in 'more stable'. > I would have thought that the machine would be stable after disabling > NCQ; do you still see issues after disabling NCQ? I was inaccurate when I said "more": it has been totally stable since disabling NCQ on that port. > As for the NCQ issues: it might be that the adapter has issues with NCQ > (quite some older adapters do). > It might also be a problem with the _previous_ command which failed; can > you enable libata tracing to figure out the command flow? OK I'll see if I can get around to this one tomorrow. Cheers! -- Sitsofe | http://sucs.org/~sits/
