[SATLUG] simultaneously burning multiple DVDs

Craig sargonemail at gmail.com
Thu Jan 1 21:54:32 CST 2015


^> Christopher Chavez chrischavez at gmx.us on Thu Jan 1 11:02:17 CST 2015
wrote:
^>
^> This reply seems to have fallen behind to the point others have probably
^> mentioned all of what I was going for (cf. Craig's links)...
^>
^> > Maybe the bottleneck is the controller chipset for the DVD writer.
This may
^> > use a limited buffer to spool the data to write from and is not
designed for
^> > multiple devices. The DVD system software maybe the bottleneck because
it can
^> > handle one write at a time.
Don't forget there's a middle man to consider -- the OS!

^> The SATA controller would not have such a buffer for optical drives. A
typical
^> PC only contains buffers in the individual writers; the exceptions would
be e.g.
^> a RAID/SSD cache (for hard drives of course) or standalone disc
duplication
^> units. Each disc burning command also keeps a cache in RAM while burning
(wodim
^> uses 4MB for its "fifo" by default).
Note: OS system has "buffers" for device too e.g. "|"
"fs=" option to cdrecord determines the RAM cache size.

^> Cf. "Process Scheduling Priority", http://linux.die.net/man/1/wodim
^> I did not think that would be the issue, given how the system has 6-core
CPU.
Yes, but only one main bus that is shared between the various dvd/cd
burners (e.g.
each CPU core doesn't get it's own dedicated, direct link bus between core,
main memory,
and the associated cd/dvd).

^> Disc burning is done using a lot of commands to control the burning
process
^> (SCSI ioctl) rather than just block data transfer, so what I suggested
earlier
^> (the read throughput benchmark) might not be sufficient.
Note: block data transfers and ioctl's are not the same thing as async/sync
reads/writes!

^> The issue at the moment seems to be that these control commands are
becoming congested.
Sounds like DMA kernel parameters are not set/tuned to handle more than one
drive.

^> This is probably the most interesting thing I've come across:
^> https://bugzilla.redhat.com/show_bug.cgi?id=877470
^> Comment 17 in particular: in a way, this issue is a kernel regression,
and there
^> was a patch that never made it into the kernel due to potentially
introducing
^> new issues.
As I recall, the ISO image being stored on the ramdrive was a prebuilt
-- so mkisofs wouldn't be an issue.
It does sound like something that could be taken care of via kernel
tuneables.

^> K3B - Cannot burn concurrently to multiple recorders
^> https://bugs.kde.org/show_bug.cgi?id=179217
^> Might want to change this to CONFIRMED.
^>
^> This seems to have become quite a popular thread, and I've learned a lot
about
^> this issue. In my spare time I might want to see if I can help look into
this
^> (I'm an undergrad student on vacation at the moment). I'm inclined for
this to
^> be fixed for everyone rather than have to run out and buy more hardware
to solve
^> the problem, as fun as it sounds.
^>
^> Christopher Chavez

The list has served it's purpose well!

Craig


More information about the SATLUG mailing list