Re: Low burning speed

[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\ 
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 

Re: Low burning speed

[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]