[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Low burning speed

 181403648/4220336128 ( 4.3%) @6.0x, remaining 11:30 RBU  99.1% UBU  84.6%
 209125376/4220336128 ( 5.0%) @6.0x, remaining 10:52 RBU 100.0% UBU  80.8%
 232062976/4220336128 ( 5.5%) @5.0x, remaining 10:53 RBU 100.0% UBU  73.1%
 241631232/4220336128 ( 5.7%) @2.1x, remaining 11:15 RBU  98.9% UBU  30.8%
 256933888/4220336128 ( 6.1%) @3.3x, remaining 11:18 RBU 100.0% UBU  19.2%

So not a single SYNC CACHE? ... Moving on to next probable suspect, unit lying about available buffer capacity. Open growisofs_mmc.cpp in text editor, locate lines that read

            if (msecs>=0)
            {   poll (NULL,0,msecs);

(line #637 in 7.1) and modify it as following:

            if (msecs>=0)
            {   fprintf(stderr,"--- %d %d %d\n",msecs,bsize,bfree);
                poll (NULL,0,msecs);

The drive seems to be willing to run at the speed which
is announced for the first part of the media: 6.0x.
The fact that the drive buffer (UBU) after a short time
of burning has less than 20 % fill indicates that there
is a problem with data transfer from computer to drive.

Well, not necessarily. In growisofs case when unit returns "long write in progress", it takes a nap for estimated time to drain buffer to 1/2 of its capacity. Then it should be noted that UBU value is *minimum* observed value for progress indicator update period. So that *if* unit returns "long write in progress" a lot, it would be normal to observe UBU lying around 50%. If not below, because system timer doesn't provide enough accuracy to nail 50% mark exactly. Note that I'm only saying that UBU values below 50% do not *necessarily* indicate a problem! I'm *not* saying that it's not a problem indication in *this* case:-)

Effective throughput seems to be about 4.3 MB/second.

This incident here looks quite strange:

 1882193920/4220336128 (44.6%) @3.7x, remaining 8:10 RBU 100.0% UBU  26.9%
 1883176960/4220336128 (44.6%) @0.2x, remaining 8:13 RBU 100.0% UBU 100.0%
 1883176960/4220336128 (44.6%) @0.0x, remaining 8:17 RBU 100.0% UBU 100.0%
 1886191616/4220336128 (44.7%) @0.7x, remaining 8:21 RBU 100.0% UBU  15.4%

Drive buffer is reported as full, but there is no
substantial data transfer for a short time.

This usually happens when recording crosses the velocity zone boundary. Though it's too early if one trusts write performance descriptor [in one previous posts it was at 112640*2K=230686720]...

This cannot be blamed on a bad throughput.

Maybe the drive buffer ran empty and the drive
decided to wait until it is at 100 % again.
Then it needed some time to speed up disc rotation

Experiment proposal:

Would it work with better speed if you do not
burn the ISO image on the fly but first generate
it in a disk file and afterwards burn that file
to media ?

Also, in case it's not executed as root, try to execute growisofs as root.

For simplicity you could omit the mkisofs run
and just create a dummy file of 4 GB:
  dd if=/dev/zero of=/tmp/4gb_of_zeros bs=1M count=4096

(1 GB = count=1024 should suffice too.)

This file could be burned to media by various programs:

  growisofs -use-the-force-luke -Z /dev/sr0=/tmp/4gb_of_zeros

Or simply 'growisofs -Z /dev/dvd=/dev/zero'. This will guarantee that there is no interference from file system. A.

Reply to: