[SATLUG] simultaneously burning multiple DVDs

Borries Demeler demeler at biochem.uthscsa.edu
Sun Dec 28 20:48:22 CST 2014


On Sun, Dec 28, 2014 at 08:08:47PM -0600, Christopher Chavez wrote:
> > On Sun, Dec 28, 2014 at 02:49:12PM -0600, Samuel Smith wrote:
> > > On 12/26/2014 12:14 PM, Borries Demeler wrote:
> > > >Recently a question has come up for which I do not have a good answer -
> > > >does anyone have a good explanation for this:
> > > >
> > > >If one has multiple DVD writers installed and wants to make multiple
> > > >copies of the same iso file by simultaneously writing them to all
> > > >installed DVD writers, such an operation produces faulty drives.
> > > >Furthermore, K3B does not allow writing to multiple drives - there must
> > > >be a reason for that.
> > > >
> > > >I am trying to figure out where the bottleneck is. Initially, I suspected
> > > >that the harddrive my not be fast enough to be read by multiple cdrecord
> > > >instances. But copying the iso file to a ramdrive and burning with the
> > > >ramdrive location as the source offered little to no improvement. The
> > > >SATA drives (configured as a RAID) should not be a bottleneck. I measured
> > > >the sustained read speed to be no less than 150 MB/sec.
> > > >
> > > >Is there is a solution so one can write to multiple writable DVD drives,
> > > >and where is the bottleneck? Does anyone have experience with this
> > > >particular problem?
> > > >
> > > >Thanks, and happy holidays to all! -borries
> > > >
> > >
> > >
> > > K3B is basically just a wrapper around several command line tools
> > > that burn disks. You could I suppose, just run those commands as
> > > many times as needed in parallel. Never tried it though.
> > >
> > > --Sam
> > When I said "such an operation produces faulty drives" I meant to say
> > faulty DVDs. Those faulty DVDs were created by running multiple instances
> > of cdrecord, a commandline tool.  All works well when running one copy,
> > but more than one simultaneous burn operation causes the bad DVDs (audio
> > skips, for example). The problem gets worse the higher the number of
> > simultaneous write operations, even when the source iso file is on a
> > ramdrive. Just curious where the bottleneck is and what to do about it.
> 
> The bottleneck could be in how the DVD writers are connected. If I'm not
> mistaken you have only mentioned how the hard drives were connected, and I
> would agree that it is not a bottleneck in this instance.
> How are the DVD drives connected? Depending on the burning speed, I've read
> that an interface like a single PATA/IDE channel shared between two drives,
> especially without an 80 conductor cable, or USB 2.0 DVD writers connected
> through a hub, can lead to burn failure from buffer underrun. Some
> drives/programs have an option to try using "buffer underrun protection"
> provided by the DVD writer; in cdrecord (a.k.a. wodim, which are used by K3B),
> this had to be enabled manually in older versions (driveropts=burnfree) but it
> is now enabled by default. Some BIOSes have options that prevent PATA/IDE from
> operating at the highest speeds supported by the drives, so those may also be
> checked.

I am aware of the limitations with PATA connected drives, especially if 
they are on the same cable. All the drives here are modern, high speed 
SATA drives. This is a modern 6-core AMD system with 16 GB RAM that 
should be generously enough configured for burning 4 disks simultaneously.

> I'm not certain this always works, but probably the only workaround if the
> DVD writer's interface is simply too slow is to force burning at a lower speed
> (wodim speed=#). I think another way to possibly detect bottlenecks is to try

That's a thought, and I will try this, even though it would sort of defeat the purpose.

> benchmarking the read speed from the burners individually and/or
> simultaneously; this may identify a safe upper burning speed.
> Cf. http://en.wikipedia.org/wiki/DVD#Transfer_rates and
> http://en.wikipedia.org/wiki/List_of_device_bit_rates

Interesting, the system bus for the board and the SATA drives should be more than
sufficient to support this, so I am still baffled where the bottleneck is,
Is there another bus that would be involved?

Thanks, -Borries


More information about the SATLUG mailing list