[Paranoia] Parallel ripping causes extreme slowdowns

[Merlijn B.W. Wajer]

Hi,

On 14/12/2019 12:56, grarpamp wrote:
> On 12/14/19, Merlijn Wajer <merlijn at wizzup.org> wrote:
>> In general, we use Intel NUC
>> Linux 5.0.
>> PL2773 SATAII bridge controller - USB
>> Liteon ODD "iHAS 124"
> 
>> the internal USB bus and the thunderbolt3 interface.
> 
> Thunderbolt is PCI and DP... separate from USB,
> unless using the USB controller part of t3.

This is indeed what I meant: a separate USB controller on Thunderbolt3,
it registers as a separate one in Linux at least.

>> (Tangent: USB2 has a limit of 480Mbit/s if I recall correctly, so that
>> should really be no problem for two drives?)
> 
> CD 1x is roughly 150kB/s, they would self destruct before then.

Agreed.


>> It tries to
>> reset and re-read, and while that happens, the other two drives are just
>> blocking. As far as I can tell, there should be no reason for that to
>> happen, but it suggests that the problem is not cdparanoia (as
>> expected), but rather somewhere on the scsi or driver level?
> 
> The usb or scsi layer driver could be going through some
> form of lock waiting on the drive or hw, that could take
> out all consumers of the driver regardless of bus.
> Or if all the drives are on the same bus or drive controller,
> a reset etc to either of those two hw could freeze everything
> downstream of them till it resolves.

I think something like this is happening too. The drives (at least per
sysfs) do not seem to be on the same bus - every USB drive seems to have
it's own 'scsi controller' and is on bus 0. (I am not at the machines
right not, but will verify when I am at the machines on Monday)

I will try to get some more information/insight. Once I have some more,
maybe linux-scsi is not a bad place to mail as well.

>> Do you have suggestions for tools and settings to use to investigate the
>> possibly activity that you mention?
> 
> The debug level you have set could be filtered to make
> things more visible for you... there's piles of the same
> 12 byte commands, probably boring reads.
> 
> Search for scsi / ata command set, scsi / sg / sr manpage.

Right, I've seen tools to change scsi logging, although it seems to log
to kernel ring buffer, but I guess that's workable.

> Strace would capture the application sw, but there's
> probably some driver specific debug options.

For sure - it's not the right tool to properly debug scsi - but it
helped me confirm that indeed, some of the ioctl()'s were blocking as
soon as one drive had an issue.

> If you think it's something in the Linux kernel and want
> to check another OS... do an install, or try in ram...

Will try this once I get a little further. Alternative option is to do
run a VM with usb passthrough of the USB drive (before it registers in
the host as scsi device), perhaps. (Although that of course might
introduce other complications, PCI passthrough of a USB host controller
might be easier).

Will be back with more information or more questions eventually.

Regards,
Merlijn

> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.1/
> Pick latest -rnum-memstick.img.xz
> xzcat | dd of=stickdev
> boot
> shell
> ifconfig -a
> ifconfig <dev> n.n.n.n/mask
> route add default g.g.g.g
> man resolv.conf
> pkg install cdparanoia
> or
> fetch http://pkg.freebsd.org/FreeBSD:12:amd64/latest/All/cdparanoia-3.9.8_10.txz
> LD_LIBRARY_PATH=./lib ./bin/cdparanoia
> mkdir /tmp/rips
> mdmfs -s 1g md /tmp/rips
> dmesg | egrep '(da|cd).*device|sectors'
> cdparanoia /dev/... to /tmp/rips or /dev/null
> 
> https://freebsd.org/ports/
> https://www.freebsd.org/handbook/
> See also cdrtools-devel to test another ripper.
> _______________________________________________
> Paranoia mailing list
> Paranoia at xiph.org
> http://lists.xiph.org/mailman/listinfo/paranoia
>