Burning some files in a data DVD using brasero is very slow. I get 2.6x
speed at most and my drive is 8x capable. Using growisofs directly,
i get a 6.6x speed average (which seems reasonable for a 8x drive).

reassign 567056 libburn4
thanks

Le mardi 26 janvier 2010 à 20:03 -0300, Leandro Lucarella a écrit :

My guess goes for a bug in libburn; one specific to the drive, since I
haven’t noticed such a slowdown with my 16x burner.

What is your burner’s model?

Cheers,

Josselin Mouette, el 27 de enero a las 17:41 me escribiste:

*-cdrom
   description: DVD writer
   product: LITE-ON DVDRW SOHW-832S
   physical id: 0
   bus info: ide@0.0
   logical name: /dev/hda
   version: CG5M
   serial: 2004031900044536
   capabilities: packet atapi cdrom removable nonmagnetic dma lba iordy audio cd-r cd-rw dvd dvd-r
   configuration: mode=udma2 status=ready
   *-medium
      physical id: 0
      logical name: /dev/hda

tags 567056 + moreinfo
thanks

Hi,

Which version of libburn was used, since it is not listed in the initial mail.

Thomas, do you have any rough idea what might be the cause for such low rates
to be picked as compared to growisofs?

Hi,

Leandro Lucarella:
Josselin Mouette:
George Danchev:
One of my USB drives was slower with libburn
than with growisofs. Users had similar problems.

The reason is not really clear. External drives
changed their speed when being plugged into
another computer. eSATA was faster than USB with
the same drive and computer.
growisofs did not always outperform libburn.

With some drives speed got improved by using
libburn ./configure options
  --enable-dvd-obs-64k
or
  --enable-track-src-odirect
and then
  make clean ; make

Without compiling, one may also use cdrskin or
xorriso for experiments.
  cdrskin ... dvd_obs=64k ...
  xorriso ... -dvd_obs 64k ...

Inside Brasero one could use for testing:
  void burn_write_opts_set_dvd_obs(struct burn_write_opts *opts, int obs);
with obs = 65536 .
The call is available since libburn-0.7.4
(december 2009).

Are there any indications that DMA might not
really be in effect ?
(Hopping cursor, high CPU load with "WAIT".)

Do you get better throughput if running the
program as superuser ?


Have a nice day :)

Thomas

Hi,

reading the initial message on
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567056
and especially the list
  "Versions of packages brasero depends on:"
i wonder whether libburn is involved at all.

In
http://packages.debian.org/sid/libbrasero-media0
i read that it depends on
  dvd+rw-tools
and on
  libburn4

Which one acted during the burn ?


Even if it was actually not libburn, then i am
still interested in exploring the problem.
libburn and growisofs rely on the same MMC specs
and system interfaces.
Actually growisofs source often helped me to
understand the specs.


Have a nice day :)

Thomas

Quoting "Thomas Schmitt" <scdbackup@gmx.net>:

Hi,

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

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.

Leandro, testing with cdrskin and xorriso and these options (see man
for examples) would help us to deduce whether the source of that
slowness has anything to do with libburn itself. Could you please
provide us with your results?

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 can also see a similar issue reported against dvd+rw-tools [1]

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562983
http://lists.alioth.debian.org/pipermail/pkg-opt-media-team/2009-December/000070.html

Hi,
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.

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
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.

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

Hi, I'm sorry about the delay, I was a little busy.

See the comments below.


George Danchev, el 30 de enero a las 11:01 me escribiste:

It was 0.7.4.pl01-1. I do regular updates so now I have 0.7.6.pl00-2.

I just burned (in simulation mode) a DVD and it worked fine, it reaches 8x
for most of the time (I see an unrelated bug, the progress fails because
the total size reported to be burned is "-2147483648 MiB", the "-" is not
a typo, so the progress was always 0). I cancelled the simulation before
reaching the 4GB to burn so I don't know what it would happened if
I didn't.

I burned a DVD (without simulation) and the speed is slow again. In the
simulated test burnproof was not set but in the real burn it was (but I've
tested changing the burnproof option before and it made no difference).
The data wasn't the same either, but was files from about the same time,
taken from the same HD (even the same FS). The burning failed, so I was
able to see the Brasero log and it looks like it's using growisofs, which
is a little odd since growisofs works fine for me (Brasero is using some
"use-the-force-luke" options that I don't though). But I might be
misreading the (attached[1]) log.

Please, first confirm if my suspicions that Brasero is using growisfs are
not true first :)

Exactly, and I saw the kernel messages and never got errors about DMA.

Just in case it provides any information, GnomeBaker works fine too (I
don't know if it uses growisofs or what).

Thanks.

[1] Files information removed from the log for privacy reasons :)

As I said in the previous mails, I think Brasero is burning stuff using
growisofs, but just in case:

Thomas Schmitt, el 30 de enero a las 12:24 me escribiste:

In Debian they are different packages, but I can install it.

The test went just fine, at reasonable speed (I'll sent to you the log).

reassign 567056 brasero
thanks

I hereby reassign that back to brasero, since the reporter suggests that it is
not libburn used during the slow burn, nor it is growisofs used alone which
was slow. So I got the impression that it is how brasero interacts with
growisofs.

Leandro Lucarella writes:
-- 
pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>

Hi,

Yes, it is growisofs working.
The options are ok for a burn run without mkisofs
being run by growisofs itself. (Normally it forks
mkisofs and writes its output to media. Here we
have the cdrecord-like use case of just burning.)

It is hungry for input.

RBU (= Ring Buffer Usage ?) is the fifo where
growisofs buffers the input. This one is always
low through the whole burn. Only at start it was
full.

UBU (= Unit Buffer Usage ?) is the drive's
buffer (1 or 2 MB). It oscillates between
0 % and 100 %. The latter happens only when the
drive is completely out of data and takes a
rest to wait for more input.

This pattern tells me that Brasero cannot feed
growisofs fast enough. Probably because its ISO
filesystem generator cannot gather its own
input fast enough.

Are there many small files involved ?
Or a slow disk from where Brasero shall read ?

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

Slow start. Contemporary burners begin with 6x.

Next speed zone reached. The burner accelerates.

Final speed of 8x reached ...

... and pertained up to the end.


Your drive and its bus connection are ok for 8x.
The problem is at the input side of the burn
program.


Have a nice day :)

Thomas

Hi,

i forgot to mention that probably i am in charge
for any problems _inside_ the ISO generator.

The log says:

I assume this is our libburnia libisofs.

So if growisofs+mkisofs is substantially faster
with the same file set than Brasero, we will
have to explore the reason inside libisofs
or in its connection to Brasero.


Have a nice day :)

Thomas

Thomas Schmitt, el  8 de febrero a las 09:35 me escribiste:

:)

Yes, growisofs is faster than Brasero under the same conditions (same
files, same disk, same burner, same media).


Thanks.

Hi, Thomas.

Thomas Schmitt, el  8 de febrero a las 08:28 me escribiste:
[snip]

Nope, just a dozen of big files.

Nope, the same disk I use to burn with growisofs directly.

[snip]

Thanks for the analysis.

Hi,

for some reason i did not get the last two
mails from Leandro.
Only good that George brought me back to the
topic.


I propose to next explore libisofs without a
burn process being involved.
If Brasero can burn to a disk file as "drive"
target, then try whether it is as slow as with
optical media.

Another test would be to install xorriso.
E.g. by
  apt-get source libisoburn

or from source
http://scdbackup.sourceforge.net/xorriso-0.4.8.pl01.tar.gz
build by:
 tar xzf ..../xorriso-0.4.8.pl01.tar.gz
 cd xorriso-0.4.8
 ./configure
 make
 make install (or execute as ./xorriso/xorriso)

One my run it by its mkisofs emulation

  xorriso -as mkisofs -o /dev/null \
          -R -J \
          file_or_dir_1 file_or_dir_2 ...

which will tell no speed numbers.
Or by its own CLI

  xorriso -outdev stdio:/dev/null \
          -add file_or_dir_1 file_or_dir_2 ...

which will give a progress report with DVD speed
measurements
  xorriso : UPDATE : Writing:    3257s    0.5%   fifo   0%  buf  50%
  xorriso : UPDATE : Writing:   20875s    3.0%   fifo   0%  buf  50%   62.7xD
  ...
  xorriso : UPDATE : Writing:  664063s   96.8%   fifo   0%  buf  50%   56.4xD
  ISO image produced: 685604 sectors

This is on a 3000 MHz AMD. About 20 times faster
than you experience with Brasero.

If this works fast, then you should try a
dummy run with DVD-R:

  xorriso -outdev /dev/sr0 -dummy on \
          -add file_or_dir_1 file_or_dir_2 ...


If any of the xorriso tests is slow, then i will
have to invent a theory and some experiments to
verify it.
(Any hint is welcome then.)

If they all are fast, then one will have to
search the bottleneck in Brasero.


Have a nice day :)

Thomas

Thomas Schmitt, el 11 de febrero a las 22:41 me escribiste:

I'm sorry, I'm running a home mail server using a dynamic IP address and
a lot of spammer listing services don't like that, it probably failed to
deliver the e-mail because of that...

Yes, it does. It took about 4.5 minutes to build a 4.4GB image.

But it seems like Brasero uses growisofs, and AFAIK growisofs doesn't use
libisoburn to make the image, right? Even more, installing xorriso
I realized I didn't even had libisoburn1 installed, so I guess braser
couldn't possibly make the image using it. Is there any point on trying
this?

Thanks!

Hi,

Your mails are marked as "spam" but i do not
allow my mail provider's automat to drop any
mails.

I now got the two missing mails
  Date: Mon, 8 Feb 2010 15:14:58 -0300
  Date: Mon, 8 Feb 2010 15:16:11 -0300
just together with your newest mail
  Date: Thu, 11 Feb 2010 21:11:35 -0300
The culprit seems to be
  host33.190-230-6.telecom.net.ar
which sat on the mails since monday,
according to "Received:" headers.
(Your own machine ?)

That's about 16 MB/s = 12 x DVD speed.

Not overly fast but no reason to slow down
burning to 2.5 DVD speed.

The proposed xorriso commands would do a similar
run as Brasero did with the disk file as "drive".
The data would flow through an interface object
between libisofs and libburn. libburn would
forward them to the fastest known consumer:
/dev/null.
I.e. the gathering of input data and production
of the ISO image stream would be the same as
in Brasero. The further data processing would
not.

It might be that this experiment becomes
necessary if there cannot be found a reason why
Brasero produces its ISO image at >= 12x speed
but hands it over to growisofs at only 2.5.


So, now we should ask the brasero developers
whether they have an idea what could be the
bottleneck between libisofs and growisofs.

If there is no insight emerging, then you should
make a xorriso dummy run on DVD-R.
Maybe we are "lucky" by seeing a similarly bad
performance. Then i would have a jacking point
for own examinations.


Have a nice day :)

Thomas

Dear Customer,

We can not deliver your parcel arrived at February 23.

Review the document that is attached to this e-mail!

Respectfully yours,
Arthur Goldberg,
UPS Senior Delivery Manager.

Παρακαλώ, ποιος είναι ο καλύτερος τρόπος επικοινωνίας μαζί σας; Σου έστειλα
email αλλά επανήλθε, απαντήστε επειγόντως