[Paranoia] Parallel ripping causes extreme slowdowns

[Merlijn Wajer]

Hi,

Thank you for the swift reply, much appreciated.

Inline some information, and at the bottom some observation/video that
might help get to the root of the issue.

On 14/12/2019 08:31, grarpamp wrote:
> On 12/13/19, Merlijn B.W. Wajer <merlijn at archive.org> wrote:
>> how to approach fixing this problem.
> 
>> I have four drives happily ripping at good speeds, but -- the moment
>> scsi read errors occur (or when cdrdao runs!), all the drives just slow
>> down to a halt.
> 
> Some general notes on the hardware side...
> 
> The list probably doesn't have enough info about your
> particular setup to help...
> 
> - CPU model
> - Motherboard model
> - OS and version
> - Drive models
> - Converter models

In general, we use Intel NUC units running Ubuntu 18.04. NUC6i5 and
NUC7i5, all running Linux 5.0.

The converter model is a PL2773 (Prolific PL2773 SATAII bridge
controller - USB IDs 067b:2773). The drive in use are the Liteon ODD
"iHAS 124" (we've been using these for years).

I also have a ASM1051E (ASMedia ASM1051E Sata Gbs bridge - USB IDs
174c:55aa). For this I have a different drive -- ASUS DRW-24D5MT.
Neither this converter or drive have I used in my tests, though.

> What you have plugged into which busses, exactly.

I've done several tests, but they all result in the same behaviour. The
NUC has four ports, as far as I can tell all on the same USB BUS. Then
it has a thunderbolt3 interface where I (in some tests) attached a
thunderbolt USB controller. I've had drives in various configurations on
the internal USB bus and the thunderbolt3 interface.

Typically I have everything one USB2 busses, because in the past Linux
had some issues with USB3. Observations in this email and my past email
are the same for both USB2 and USB3.

(Tangent: USB2 has a limit of 480Mbit/s if I recall correctly, so that
should really be no problem for two drives?)

> Are your motherboard, os, drives, etc all running
> latest bios, firmware, code, etc.

I will check and get back to you about that --

> Converters can be quite buggy, try to avoid them, really.
> USB are often as quirky, and prone to cable / connector
> issues from abuse and wear.

Understood.

> Yes try sata drives directly to motherboard sata ports.
> Similarly, avoid multipliers, though extra pci sata port
> jbod add in cards are usually ok. Old pata and scsi are
> good too. Once things get properly tested and isolated
> as needed.

Right.
> Don't exceed the i/o capacity of any bus... that can
> trigger streaming failures, renegotiation cycles, etc.
> Check motherboard manual for bus layout and
> bandwidth allocation, wikipedia for various speeds.

I don't think I am.

> Your present setup might be seeing buggy cascading
> bus or device resets / lockups, interrupt meltdowns or
> some such. Some OS tools and settings will let you
> watch or log that activity. It's separate from iops and bytes.
> 
> Some OS tools exist to force bus and device resets, reinit, rescans...
> that might save you a hard reboot, but won't solve underlying problems.

I made a small recording with gtk-recordmydesktop of three cdparanoia's
running at the same time, all being logged with strace. About 13 seconds
in, you will see the terminal in the middle runs into to scsi_read
errors (due to scratches on the CD, as far as I can tell). 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?

https://wizzup.org/cdp-scsi-hang.mp4

Do you have suggestions for tools and settings to use to investigate the
possibly activity that you mention?

> Yes, settable modepages exist for sata, pata, scsi, usb drives...
> that might let you fiddle with per device cache control, error
> handling, etc beyond what the basic OS or ripper tools would.
> Probably better to try different hardware than time trying that.

Hm... Would prefer trying to understand the problem. It'd be a lot of
hardware to swap out.

> Start with a single drive connected that passes all your tests.
> Add in other drives... one drive, change, and test at a time.
> Keep notes.

A single drive (iHAS 124) with my normal converter (pl2773) passes all
the tests. All three of the ones I currently use individually are fine,
the problem occurs when multiple are running and one of them runs into
scsi_read errors, it seems.

Regards,
Merlijn