[SATLUG] simultaneously burning multiple DVDs
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
^> 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.
^> > use a limited buffer to spool the data to write from and is not
^> > multiple devices. The DVD system software maybe the bottleneck because
^> > 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
^> PC only contains buffers in the individual writers; the exceptions would
^> a RAID/SSD cache (for hard drives of course) or standalone disc
^> units. Each disc burning command also keeps a cache in RAM while burning
^> 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
Yes, but only one main bus that is shared between the various dvd/cd
each CPU core doesn't get it's own dedicated, direct link bus between core,
and the associated cd/dvd).
^> Disc burning is done using a lot of commands to control the burning
^> (SCSI ioctl) rather than just block data transfer, so what I suggested
^> (the read throughput benchmark) might not be sufficient.
Note: block data transfers and ioctl's are not the same thing as async/sync
^> The issue at the moment seems to be that these control commands are
Sounds like DMA kernel parameters are not set/tuned to handle more than one
^> This is probably the most interesting thing I've come across:
^> Comment 17 in particular: in a way, this issue is a kernel regression,
^> was a patch that never made it into the kernel due to potentially
^> 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
^> K3B - Cannot burn concurrently to multiple recorders
^> Might want to change this to CONFIRMED.
^> This seems to have become quite a popular thread, and I've learned a lot
^> this issue. In my spare time I might want to see if I can help look into
^> (I'm an undergrad student on vacation at the moment). I'm inclined for
^> be fixed for everyone rather than have to run out and buy more hardware
^> the problem, as fun as it sounds.
^> Christopher Chavez
The list has served it's purpose well!
More information about the SATLUG