Looking for speed testers with concurrent SG_IO reading of two DVD drives

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

are users here who have two optical drives attached to a Debian 10 amd64
system and are willing to test their speeds with concurrently reading data
from DVD or BD media via SG_IO ?

Do these two simultaneous runs (after unmounting /dev/sr0 and /dev/sr1)

  xorriso -outdev /dev/sr0 -check_media use=outdev what=disc --
  xorriso -outdev /dev/sr1 -check_media use=outdev what=disc --

show substantially lower speed numbers than these simultaneous runs

  xorriso -scsi_dev_family sg \
          -outdev /dev/sr0 -check_media use=outdev what=disc --
  xorriso -scsi_dev_family sg \
          -outdev /dev/sr1 -check_media use=outdev what=disc --

or than runs with only one busy drive ?

The speeds are shown at the end of the pacifier lines, like

  xorriso : UPDATE : 11618304 of 11826176 blocks read in 747 s , 10.0xB

or

  xorriso : UPDATE : 2284896 of 2295104 blocks read in 370 s , 13.2xD

("xD" means DVD speed 1385 KB/s , "xB" means BD speed 4495 KB/s).

Speeds normally increase towards the end of the medium. So the last speeds
when both drives are still working are of most interest.
The last pacifier of such a run gives the total speed from start to end
(note the '=' character instead of ','):

  xorriso : UPDATE : 11826176 of 11826176 blocks read in 757 s = 7.1xB
  xorriso : UPDATE : 2295104 of 2295104 blocks read in 371 s = 9.1xD

Results from older Debians would be of interest, too.

It is not necessary to show the full -check_media reports. Just show
some significant pacifier lines out of the course of reading.
If it seems interesting to show the full report (e.g. because of speed
jumps), then please send it to me in private.

--------------------------------------------------------------------------
Why i ask:

With the knocking HDD in mercantile processing and the obscure BERT report
still persisting without any visible symptoms at run time, i tend towards
the software.

So that nobody thinks i would be afraid, i plan to start with fixing old
kernel bugs around /dev/sr and ISO 9660. At least for myself, if not for
the world.

First step is to verify that the problems still exist.
#1: "No medium found" when auto-loading the DVD tray by dd: Still persists.

But #2 on my list, the concurrency problem with SG_IO and /dev/sr seems
mitigated, albeit not really solved.

Reading while the other drive is idle yields up to 10x BD and 13x DVD speed.
The same performance is shown when reading concurrently via /dev/sg*.

Concurrent reading sr0 and sr1 yields 5x BD and 13x DVD speed.
So BD is still hampered, but DVD speed seems normal.

Concurrent SATA sr0 and USB sr2 yield 5x BD speed both.

With my older workstation and kernel 3.16, i get 0.3x BD and 1x DVD from
concurrent reading via sr and up to about 5.5xBD if running alone or via sg
(dd can get up to 7xBD).

Details about the concurrency problem and its culprit can be seen at
  https://dev.lovelyhq.com/libburnia/web/wiki/ConcurrentLinuxSr


Now i wonder whether the new hardware is the decisive difference or
whether the kernel made some progress, despite the brainless mutex in
drivers/scsi/sr.c function sr_block_ioctl().
It seems not plausible that either, hardware or lower SCSI drivers,
could mitigate the strict global serialization of ioctls that is enforced
by
        mutex_lock(&sr_mutex);

Two BD drives show half throughput each.
So my best theory is that a kind of modesty mode was disabled which caused
the ioctls on kernel 3.16 to be delayed even more than necessary because
they were perceived as slow and thus should get out of the way of ioctls
which react faster. (Like those of dd via read(2), which is not hampered
by a mutex.)

But why isn't the DVD drive hampered at all ?
The BD drive can hardly answer faster than the time span which libburn
needs after receiving answer from the first DVD ioctl and before calling
the next ioctl to DVD.

Well, it still seems rewarding to remove the mutex, although the gain
is not as spectacular as expected from my experience with the old machine.

--------------------------------------------------------------------------

Have a nice day :)

Thomas