[Pkg-libburnia-devel] Bug#567056: brasero: Brasero is very slow burning a data DVD-R

[Thomas Schmitt]

Hi,

> >   --enable-dvd-obs-64k
> > or
> >   --enable-track-src-odirect
> Thomas,
> I'm not actually sure whether these options would affect the rest of the
> drives and use cases in an unpredicted way. If they are safe, I'm more than
> happy to enable them in the next package upload, so that the library users
> would benefit as well.

Currently i know of no hard reason not to use
64k blocks on output. The size of growisofs is
32k nevertheless, and libburn is most tested with
32k.
The reason for slow drives is not really idenfied
yet. 64k helped in some situations and had no
visible effect in others.

O_DIRECT is an obscure modification of i/o.
Input in this case, not output to drive.
The kernel people hate it:
  http://kerneltrap.org/node/7563
But Andy Polyakov, the author of growisofs is
much in favor of using it.
It is supposed to take workload from the system.

Normally i follow the kernel advise. It had not
much of a positive effect in my own tries.
But i never heard of a drive that would do as
slow as 2.6x under DMA.
So in this case it might be worth a try.


> Okay, however, the reporter said the speed was fine with growisofs, so if it
> was a DMA settings it would also affect growisofs burning job.

I know that DMA gets disabled if the system
drivers encounter certain errors with the
drive.
One should run (as superuser)
  hdparm -d /dev/hda | fgrep using_dma
which would reply
   using_dma    =  1 (on)
or 
   using_dma    =  0 (off)

To be done before and after the burn runs.

One may (re-)enable DMA by
  hdparm -d1 /dev/hda 


> Leandro, testing with cdrskin and xorriso and these options (see man for
> examples)

I would propose to use DVD-R in dummy mode, so
we waste no media and can test high speed.
(Not DVD+R[W]. They cannot do dummy.)

cdrskin is supposed to have been installed
together with libburn.
A test run could be this pipe:

  dd if=/dev/zero bs=1M count=4400 | \
  cdrskin -vvv dev=/dev/hda -dummy - 2>&1 | \
  tee -i /tmp/cdrskin_log

I would be interested in the file
   /tmp/cdrskin_log
afterwards.
It will be about 250kB of size. Be invited to
send it to me directly:
  scdbackup at gmx dot net

To view it yourself:
  sed -e 's/\r/\n/g' < /tmp/cdrskin_log | less

See how one of my USB burners goes slow.
Obviously its buffer fill "[buf xx%]" gets
low at about 12x speed which causes short speed
slumps and finally lets the drive reduce to 8x:

  Track 01: 1549 MB written (fifo  80%) [buf  92%]  11.5x.
  Track 01: 1550 MB written (fifo  79%) [buf  92%]  10.8x.
  Track 01: 1551 MB written (fifo  79%) [buf  92%]  11.8x.
  ...
  Track 01: 1631 MB written (fifo  78%) [buf  61%]  11.8x.
  Track 01: 1632 MB written (fifo  79%) [buf  62%]  11.5x.
  Track 01: 1633 MB written (fifo  79%) [buf  62%]  11.8x.
  ...
  Track 01: 1713 MB written (fifo  78%) [buf  14%]  11.8x.
  Track 01: 1714 MB written (fifo  77%) [buf  14%]  11.4x.
  Track 01: 1715 MB written (fifo  78%) [buf  14%]  11.5x.
  ...
  Track 01: 2366 MB written (fifo  79%) [buf  46%]  11.5x.
  Track 01: 2367 MB written (fifo  79%) [buf  46%]  11.8x.
  Track 01: 2368 MB written (fifo  85%) [buf 100%]   0.2x.
  Track 01: 2369 MB written (fifo  86%) [buf 100%]   7.9x.
  Track 01: 2370 MB written (fifo  86%) [buf  98%]   7.9x.
  Track 01: 2371 MB written (fifo  86%) [buf  98%]   8.1x.

Now the drive decided that 8x is the speed to
use.  This is an LG. Pioneer drives try full
speed up to the end.


Well, given the low speed in the bug report, real
burns on 4x DVD+RW would be no waste and should
already show slowliness.


> Leandro, could you please tell us whether libburn was actually used for
> burning and which version it was.

Maybe Josselin can answer the question whether
libburn was really in charge. At least he flatly
assumed it.

The installed libburn version can be inquired by
  cdrskin -version | fgrep 'libburn in use'


Have a nice day :)

Thomas