Re: Low burning speed

2008-03-28 Thread Andy Polyakov

 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);
continue;
}

(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);
continue;
}


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


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.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Low burning speed

2008-03-28 Thread Thomas Schmitt
Hi,

Tomasz Kaptocz wrote:
>  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%

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.

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


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

  cdrecord -v dev=/dev/sr0 /tmp/4gb_of_zeros

  cdrskin -v dev=/dev/sr0 /tmp/4gb_of_zeros

Of course, the result will not be mountable but only
bear a lot of 0-bytes. One can verify success by
  diff /dev/sr0 /tmp/4gb_of_zeros
which might report surplus bytes on /dev/sr0.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Low burning speed

2008-03-28 Thread Tomasz Kłaptocz



Dnia 26 marca 2008 17:51 Andy Polyakov <[EMAIL PROTECTED]> napisał(a):

> >>> Growiso doesn't work properly with LG GSA4163B burner and DVD+RW 8x
> >>> discs. Burning speed is about 4x (even when burner speeds up
> >>> switching from 4x zone to 8x - it's a ZCLV burner), it's well visible
> >>> with K3b. There's no problem with all other types of media, including
> >>> DVD-R 8X.
> > 
> > Version 7.0.1 and 7.1, data: big, small, in combination, doesn't
> > matter, media: Verbatim made by Mitsubishi and TDK made by Ricoh. Here's
> > output:
> > 
> > [EMAIL PROTECTED]:~$ growisofs -Z /dev/hdc /mnt/hda6/WinFast\ 
> > WorkArea/Poszukiwacze\ Czindici2.avi /mnt/hda6/WinFast\ WorkArea/odessa.avi 
> > /mnt/hda7/WinFast\ WorkArea/JFK.mpg /mnt/hda7/WinFast\ 
> > WorkArea/Nieukończony\ cud\ 2.mpg
> > WARNING: /dev/hdc already carries isofs!
> > About to execute 'mkisofs /mnt/hda6/WinFast WorkArea/Poszukiwacze 
> > Czindici2.avi /mnt/hda6/WinFast WorkArea/odessa.avi /mnt/hda7/WinFast 
> > WorkArea/JFK.mpg /mnt/hda7/WinFast WorkArea/Nieukończony cud 2.mpg | 
> > builtin_dd of=/dev/hdc obs=32k seek=0'
> > I: -input-charset not specified, using utf-8 (detected in locale settings)
> > /dev/hdc: "Current Write Speed" is 8.2x1352KBps.
> >   0.24% done, estimate finish Tue Mar 25 22:09:03 2008
> >   0.49% done, estimate finish Tue Mar 25 21:58:44 2008
> >   0.73% done, estimate finish Tue Mar 25 21:55:19 2008
> >   0.97% done, estimate finish Tue Mar 25 21:53:35 2008
> >   1.21% done, estimate finish Tue Mar 25 21:52:34 2008
> >   1.46% done, estimate finish Tue Mar 25 21:53:01 2008
> >   1.70% done, estimate finish Tue Mar 25 21:52:22 2008
> >   1.94% done, estimate finish Tue Mar 25 21:51:53 2008
> > ...
> > ...
> >  99.48% done, estimate finish Tue Mar 25 21:55:48 2008
> >  99.72% done, estimate finish Tue Mar 25 21:55:49 2008
> >  99.97% done, estimate finish Tue Mar 25 21:55:49 2008
> > Total translation table size: 0
> > Total rockridge attributes bytes: 0
> > Total directory bytes: 0
> > Path table size(bytes): 10
> > Max brk space used 0
> > 2060711 extents written (4024 MB)
> > builtin_dd: 2060720*2KB out @ average 3.6x1352KBps
> > /dev/hdc: flushing cache
> > /dev/hdc: stopping de-icing
> > /dev/hdc: writing lead-out
> 
> 3.6x with below parameters sounds like recording was progressing at 1/2 
> of advertised velocity, i.e. started at 3x and then switches to 4x at 
> about half recording. Question is does it run uniformly at 1/2 or does 
> speed jump up and down? Read on...
> 
> > And here's output of media info:
> > 
> > [EMAIL PROTECTED]:~$ dvd+rw-mediainfo /dev/hdc
> > INQUIRY:[HL-DT-ST][DVDRAM GSA-4163B][A106]
> > GET [CURRENT] CONFIGURATION:
> >  Mounted Media: 1Ah, DVD+RW
> >  Current Write Speed:   8.0x1385=11080KB/s
> >  Write Speed #0:8.0x1385=11080KB/s
> >  Write Speed #1:6.0x1385=8310KB/s
> > GET [CURRENT] PERFORMANCE:
> >  Write Performance: 6.0x1385=8310KB/[EMAIL PROTECTED] -> 112639]
> > 8.0x1385=11080KB/[EMAIL PROTECTED] -> 2295103]
> >  Speed Descriptor#0:02/2295103 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s
> >  Speed Descriptor#1:02/2295103 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s
> 
> Looks all right... I can think of following reasons (in ascending order 
> of likelihood).
> 
> 1. Even though so called Page 05 settings should not affect DVD+ 
> recordings (per MMC specification), unit looks at the page and 
> misinterprets the settings. This happened before, though not in DVD+RW 
> context.
> 
> 2. Under high-speed recordings unit lies about available buffer capacity 
> tricking growisofs to sleep for longer intervals, long enough to drain 
> the buffer and affect performance. This happened before with some 
> Pioneer units, and it should be handled, but your unit might lie in yet 
> more confusing manner.
> 
> 3. growisofs is periodically tricked to issue SYNCHRONIZE CACHE command, 
> which drains the buffer, which in turn results in idle revolutions, 
> hence lower performance.
> 
> Could you do following. Download source, unpack some place, open 
> growisofs_mmc.cpp with text editor, locate line that reads "sync_cache:" 
> (it's line 665 in 7.1), add following line after it:
> 
> fprintf(stderr,"-- SYNC CACHE %x\n",errcode);
> 
> Then 'make' and run './growisofs -use-the-force-luke=moi -Z /dev/hdc 
> /mnt/hda6/...' directly from current working directory and collect 
> output. Questions are: how does speed varies in progress indicator? 
> Steady or jerky? Do you see SYNC CACHE and if yes, how often and what's 
> the code? [There is a chance that there will be a lot of SYNC CACHE 
> lines, don't hesitate to abort recording with Ctrl-C]. How does UBU 
> value in progress indicator vary? A.
> 
> 
> I'm not sure how to interpret it so here's the whole output:

[EMAIL PROTECTED]:~/instal/dvd+rw-tools-7.1$ ./growisofs 
-use-the-force-luke=moi -Z /dev/hdc /mnt/hda6/WinFast\ WorkArea/Poszukiwacze\ 
Czindi