Re: Low burning speed
Tomasz K??aptocz <[EMAIL PROTECTED]> wrote: > 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. It's certainly growiso > problem because cdrecord.prodvd writes those disks at nominal 8x speed. > You may tell k3b to use cdrecord by default. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Low burning speed
I don't think i'm able to do it as K3b uses cdrecord only to burn CDs Dnia 18 marca 2008 16:14 [EMAIL PROTECTED] (Joerg Schilling) napisał(a): > Tomasz K??aptocz wrote: > > > 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. It's certainly > > growiso problem because cdrecord.prodvd writes those disks at nominal 8x > > speed. > > > > You may tell k3b to use cdrecord by default. > > Jörg > > -- > EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin >[EMAIL PROTECTED](uni) >[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ > URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily >
Re: Low burning speed
Tomasz K??aptocz <[EMAIL PROTECTED]> wrote: > > > > I don't think i'm able to do it as K3b uses cdrecord only to burn CDs Please _READ_ my mail.. You may tell k3b to use cdrecord by default. > Dnia 18 marca 2008 16:14 [EMAIL PROTECTED] (Joerg Schilling) napisa??(a): > > > Tomasz K??aptocz wrote: > > > > > 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. > > > It's certainly growiso problem because cdrecord.prodvd writes those disks > > > at nominal 8x speed. > > > > > > > You may tell k3b to use cdrecord by default. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Low burning speed
> 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. If you want meaningful answer, "provide versioning information, exact command line, exact output generated by the program and complement it with dvd+rw-mediainfo output for resulting recording." Quote is from dvd+rw-tools web-page. To spare bandwidth you don't have to provide *complete* output, but only relevant, at very least handful of line from beginning and end. Also, when you say "no problem with all other types of media," is it the same data set? What can you say about the data set? Is it a lot of small files or few large ones? A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Low burning speed
Dnia 21 marca 2008 20:04 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. > > If you want meaningful answer, "provide versioning information, exact > command line, exact output generated by the program and complement it > with dvd+rw-mediainfo output for resulting recording." Quote is from > dvd+rw-tools web-page. To spare bandwidth you don't have to provide > *complete* output, but only relevant, at very least handful of line from > beginning and end. Also, when you say "no problem with all other types > of media," is it the same data set? What can you say about the data set? > Is it a lot of small files or few large ones? A. > > > 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 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 READ DVD STRUCTURE[#0h]: Media Book Type: 00h, DVD-ROM book [revision 0] Media ID: MKM/A03 Legacy lead-out at:2060720*2KB=4220354560 READ DISC INFORMATION: Disc status: complete Number of Sessions:1 State of Last Session: complete Number of Tracks: 1 BG Format Status: suspended READ FORMAT CAPACITIES: formatted: 2295104*2048=4700372992 26h(0):2295104*2048=4700372992 READ TRACK INFORMATION[#1]: Track State: complete Track Start Address: 0*2KB Free Blocks: 0*2KB Track Size:2295104*2KB FABRICATED TOC: Track#1 : [EMAIL PROTECTED] Track#AA : [EMAIL PROTECTED] Multi-session Info:[EMAIL PROTECTED] READ CAPACITY: 2295104*2048=4700372992 If needed i can also provide K3b's output Tomasz > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > >
Re: Low burning speed
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.
Re: Low burning speed
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
Re: Low burning speed
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
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
>
> 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:-)
>
Output after another code modification:
[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 isofs!
About to execute 'mkisofs -quiet /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'
/dev/hdc: "Current Write Speed" is 8.2x1352KBps.
27951104/4220336128 ( 0.7%) @5.9x, remaining 14:59 RBU 100.0% UBU 3.8%
55607296/4220336128 ( 1.3%) @6.0x, remaining 11:14 RBU 100.0% UBU 80.8%
83296256/4220336128 ( 2.0%) @6.0x, remaining 10:45 RBU 100.0% UBU 80.8%
110985216/4220336128 ( 2.6%) @6.0x, remaining 9:52 RBU 100.0% UBU 69.2%
138706944/4220336128 ( 3.3%) @6.0x, remaining 9:19 RBU 100.0% UBU 73.1%
166428672/4220336128 ( 3.9%) @6.0x, remaining 9:20 RBU 100.0% UBU 80.8%
194117632/4220336128 ( 4.6%) @6.0x, remaining 8:59 RBU 100.0% UBU 84.6%
221806592/4220336128 ( 5.3%) @6.0x, remaining 8:42 RBU 100.0% UBU 80.8%
232062976/4220336128 ( 5.5%) @2.2x, remaining 9:27 RBU 100.0% UBU 80.8%
248315904/4220336128 ( 5.9%) @3.5x, remaining 9:35 RBU 100.0% UBU 15.4%
264568832/4220336128 ( 6.3%) @3.5x, remaining 9:43 RBU 100.0% UBU 23.1%
280690688/4220336128 ( 6.7%) @3.5x, remaining 10:03 RBU 100.0% UBU 23.1%
296386560/4220336128 ( 7.0%) @3.4x, remaining 10:09 RBU 100.0% UBU 15.4%
312410112/4220336128 ( 7.4%) @3.5x, remaining 10:12 RBU 100.0% UBU 15.4%
328663040/4220336128 ( 7.8%) @3.5x, remaining 10:27 RBU 100.0% UBU 23.1%
344424448/4220336128 ( 8.2%) @3.4x, remaining 10:30 RBU 100.0% UBU 11.5%
360448000/4220336128 ( 8.5%) @3.5x, remaining 10:31 RBU 100.0% UBU 23.1%
376471552/4220336128 ( 8.9%) @3.5x, remaining 10:43 RBU 100.0% UBU 15.4%
392200192/4220336128 ( 9.3%) @3.4x, remaining 10:44 RBU 100.0% UBU 23.1%
408092672/4220336128 ( 9.7%) @3.4x, remaining 10:44 RBU 100.0% UBU 34.6%
423952384/4220336128 (10.0%) @3.4x, remaining 10:53 RBU 100.0% UBU 30.8%
439910400/4220336128 (10.4%) @3.5x, remaining 10:53 RBU 100.0% UBU 11.5%
455606272/4220336128 (10.8%) @3.4x, remaining 10:52 RBU 100.0% UBU 15.4%
471597056/4220336128 (11.2%) @3.5x, remaining 10:59 RBU 100.0% UBU 15.4%
487587840/4220336128 (11.6%) @3.5x, remaining 10:58 RBU 100.0% UBU 11.5%
503578624/4220336128 (11.9%) @3.5x, remaining 10:56 RBU 100.0% UBU 15.4%
518815744/4220336128 (12.3%) @3.3x, remaining 11:03 RBU 100.0% UBU 19.2%
534708224/4220336128 (12.7%) @3.4x, remaining 11:01 RBU 100.0% UBU 26.9%
550764544/4220336128 (13.1%) @3.5x, remaining 10:59 RBU 100.0% UBU 15.4%
566886400/4220336128 (13.4%) @3.5x, remaining 11:03 RBU 100.0% UBU 26.9%
582844416/4220336128 (13.8%) @3.5x, remaining 11:01 RBU 100.0% UBU 11.5%
599097344/4220336128 (14.2%) @3.5x, remaining 10:58 RBU 100.0% UBU 23.1%
614891520/4220336128 (14.6%) @3.4x, remaining 11:02 RBU 100.0% UBU 26.9%
630718464/4220336128 (14.9%) @3.4x, remaining 11:00 RBU 100.0% UBU 30.8%
646545408/4220336128 (15.3%) @3.4x, remaining 10:57 RBU 100.0% UBU 30.8%
662503424/4220336128 (15.7%) @3.5x, remaining 11:00 RBU 100.0% UBU 11.5%
678690816/4220336128 (16.1%) @3.5x, remaining 10:57 RBU 100.0% UBU 19.2%
694681600/4220
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% 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]... Oops! I'm apparently off by factor of 10 here. Velocity zone change has taken place much earlier and at the point where performance dropped from 6x to 3.?x instead of increasing to advertised 8x. I must have failed to believe/accept that zone change can be at such low address... So it's not "too early," but "indeed quite strange." A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Low burning speed
Hi, i am participating in this discussion because i am very interested in the technical reason of Tomasz' problem. After all the DVD code of libburn is inspired by the code in dvd+rw-tools. Andy Polyakov wrote: > Velocity zone change has > taken place much earlier and at the point where performance dropped from 6x > to 3.?x instead of increasing to advertised 8x. I must have failed to > believe/accept that zone change can be at such low address... So it's not > "too early," but "indeed quite strange." It might be interesting to see what happens if speed is set to -speed=6 explicitely. In a second experiment -speed=8 could be interesing, too. Another experiment would be to use my program cdrskin which is based on libburn. Home: http://scdbackup.sourceforge.net/cdrskin_eng.html Source: http://scdbackup.sourceforge.net/cdrskin-0.4.2.pl00.tar.gz Binary: http://scdbackup.sourceforge.net/cdrskin_0.4.2.pl00-x86-suse9_0-static.tar.gz It is to be operated like cdrecord. As said, libburn's understanding of MMC DVD specs is quite similar as in growisofs. Nevertheless it is different code which i derived from hints of growisofs and from reading MMC-5 specs. So if it shows no speed decay then we would have good chances to find the decisive difference. On the other hand, if the slowdown occurs with cdrskin as with growisofs then we would have to compare our command sequences with those of cdrecord (option -V if i remember right). Regrettably i got not much chance to purchase 8x DVD+RW. One of my drives would be able to write them (TSSTcorp CDDVDW SH-S203B). Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Low burning speed
Velocity zone change has taken place much earlier and at the point where performance dropped from 6x to 3.?x instead of increasing to advertised 8x. I must have failed to believe/accept that zone change can be at such low address... So it's not "too early," but "indeed quite strange." It might be interesting to see what happens if speed is set to -speed=6 explicitely. I'd guess it would manage to record at steady 6x (but do verify it, Tomasz). As mentioned the trouble apparently comes when it crosses the velocity zone boundary. It's not surprising that when you can't deliver Nx to unit, performance drops *below* what you deliver because of forced idle revolutions. The main question is why does the system in question discriminate DVD+RW in particular. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Low burning speed
Output after another code modification: [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 isofs! About to execute 'mkisofs -quiet /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' /dev/hdc: "Current Write Speed" is 8.2x1352KBps. 27951104/4220336128 ( 0.7%) @5.9x, remaining 14:59 RBU 100.0% UBU 3.8% 55607296/4220336128 ( 1.3%) @6.0x, remaining 11:14 RBU 100.0% UBU 80.8% 83296256/4220336128 ( 2.0%) @6.0x, remaining 10:45 RBU 100.0% UBU 80.8% 110985216/4220336128 ( 2.6%) @6.0x, remaining 9:52 RBU 100.0% UBU 69.2% 138706944/4220336128 ( 3.3%) @6.0x, remaining 9:19 RBU 100.0% UBU 73.1% 166428672/4220336128 ( 3.9%) @6.0x, remaining 9:20 RBU 100.0% UBU 80.8% 194117632/4220336128 ( 4.6%) @6.0x, remaining 8:59 RBU 100.0% UBU 84.6% 221806592/4220336128 ( 5.3%) @6.0x, remaining 8:42 RBU 100.0% UBU 80.8% 232062976/4220336128 ( 5.5%) @2.2x, remaining 9:27 RBU 100.0% UBU 80.8% 248315904/4220336128 ( 5.9%) @3.5x, remaining 9:35 RBU 100.0% UBU 15.4% 264568832/4220336128 ( 6.3%) @3.5x, remaining 9:43 RBU 100.0% UBU 23.1% 280690688/4220336128 ( 6.7%) @3.5x, remaining 10:03 RBU 100.0% UBU 23.1% 296386560/4220336128 ( 7.0%) @3.4x, remaining 10:09 RBU 100.0% UBU 15.4% 312410112/4220336128 ( 7.4%) @3.5x, remaining 10:12 RBU 100.0% UBU 15.4% ... 4149411840/4220336128 (98.3%) @3.7x, remaining 0:14 RBU 100.0% UBU 11.5% 4165959680/4220336128 (98.7%) @3.6x, remaining 0:11 RBU 100.0% UBU 15.4% 4182147072/4220336128 (99.1%) @3.5x, remaining 0:07 RBU 100.0% UBU 26.9% 4210491392/4220336128 (99.8%) @6.1x, remaining 0:02 RBU 29.4% UBU 23.1% builtin_dd: 2060720*2KB out @ average 3.6x1352KBps /dev/hdc: flushing cache /dev/hdc: stopping de-icing /dev/hdc: writing lead-out So there are no SYNC CACHE or [miscalculated] sleeps involved. And as mentioned earlier (in another post) problem seem to arise when unit crosses velocity zone boundary around 220MB. This means that first, least probable, reason in my early post is even less probable or even void, because it appears as if system simply can't sustain 8x and ends up at ~1/2 of what it's capable to deliver [again, as mentioned earlier, because of forced idle revolutions]. I decided to prove that filesysyem is fast enought to write at 8x speed so i simulated DVD-R (8x) burning and burned DVD+R (16x). There's something strange with "+" media when it comes back to 8x after reaching 10x, however it is possible to write at 8x speed It *appears* to be DVD+RW specific problem and the question is how come? What kernel is it? Do you have pktcdvd loaded and configured? How come there is no sign of "reloading tray" for DVD+? BTW, could you provide dvd+rw-mediainfo for 16x DVD+R? A.
Re: Low burning speed
Hi, > The main question is why does the system in question > discriminate DVD+RW in particular. That would be explainable by faulty firmware which switches speed too early. But why does it work with full speed when cdrecord is used ? Especially with DVD+RW it is not very likely that any SCSI command before writing would influence the drive as observed by Tomasz. The drive only announces two speeds. None of them is below 6x. So growisofs should be unable to make it run slower. That's why i propose a test with cdrskin. (Elsewise growisofs is at least as capable with DVD as is cdrskin.) I forgot to propose a test with plain operating system driver: time dd if=/dev/zero of=/dev/hdc bs=1M count=1000 The measured time and the size of 1000 MiB would allow to compute the average speed. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Low burning speed
Thomas, you cracked me and i finally tried out cdrskin - it behaves just like growiso, first zone ok, second zone slowly. Growis with option "speed=6" works properly, "speed=8" like without speed option. But what's interesting growiso+K3b and speed set at 6x records at 3.5 - 4x, when 8x is checked - first zone 3.5 - 4x, second 2.5 - 3x. Another test you wanted me to do before: [EMAIL PROTECTED]:~$ growisofs -Z /dev/dvd=/dev/zero WARNING: /dev/dvd already carries isofs! About to execute 'builtin_dd if=/dev/zero of=/dev/dvd obs=32k seek=0' /dev/dvd: restarting DVD+RW format... /dev/dvd: "Current Write Speed" is 8.2x1352KBps. 18153472/4700372992 ( 0.4%) @3.7x, remaining 25:47 RBU 100.0% UBU 3.8% 45907968/4700372992 ( 1.0%) @6.0x, remaining 15:12 RBU 100.0% UBU 65.4% 73596928/4700372992 ( 1.6%) @6.0x, remaining 12:34 RBU 100.0% UBU 92.3% 101318656/4700372992 ( 2.2%) @6.0x, remaining 12:06 RBU 100.0% UBU 96.2% 129040384/4700372992 ( 2.7%) @6.0x, remaining 11:13 RBU 100.0% UBU 96.2% 156729344/4700372992 ( 3.3%) @6.0x, remaining 10:37 RBU 100.0% UBU 92.3% 184451072/4700372992 ( 3.9%) @6.0x, remaining 10:36 RBU 100.0% UBU 96.2% 212172800/4700372992 ( 4.5%) @6.0x, remaining 10:13 RBU 100.0% UBU 88.5% 232062976/4700372992 ( 4.9%) @4.3x, remaining 10:16 RBU 100.0% UBU 96.2% 254279680/4700372992 ( 5.4%) @4.8x, remaining 10:29 RBU 100.0% UBU 46.2% 286949376/4700372992 ( 6.1%) @7.1x, remaining 9:59 RBU 100.0% UBU 19.2% 319488000/4700372992 ( 6.8%) @7.0x, remaining 9:49 RBU 100.0% UBU 19.2% 352157696/4700372992 ( 7.5%) @7.1x, remaining 9:27 RBU 100.0% UBU 19.2% 384696320/4700372992 ( 8.2%) @7.0x, remaining 9:09 RBU 100.0% UBU 19.2% 417366016/4700372992 ( 8.9%) @7.1x, remaining 9:03 RBU 100.0% UBU 19.2% 450002944/4700372992 ( 9.6%) @7.1x, remaining 8:48 RBU 100.0% UBU 23.1% 482574336/4700372992 (10.3%) @7.1x, remaining 8:35 RBU 100.0% UBU 23.1% 515112960/4700372992 (11.0%) @7.0x, remaining 8:31 RBU 100.0% UBU 23.1% 547782656/4700372992 (11.7%) @7.1x, remaining 8:20 RBU 100.0% UBU 26.9% 580419584/4700372992 (12.3%) @7.1x, remaining 8:09 RBU 100.0% UBU 23.1% 613056512/4700372992 (13.0%) @7.1x, remaining 8:06 RBU 100.0% UBU 23.1% 642514944/4700372992 (13.7%) @6.4x, remaining 7:59 RBU 100.0% UBU 26.9% 675119104/4700372992 (14.4%) @7.1x, remaining 7:51 RBU 100.0% UBU 23.1% 707657728/4700372992 (15.1%) @7.0x, remaining 7:48 RBU 100.0% UBU 19.2% 740327424/4700372992 (15.8%) @7.1x, remaining 7:40 RBU 100.0% UBU 23.1% 4518215680/4700372992 (96.1%) @7.2x, remaining 0:19 RBU 100.0% UBU 26.9% 4551147520/4700372992 (96.8%) @7.1x, remaining 0:15 RBU 100.0% UBU 19.2% 4583194624/4700372992 (97.5%) @6.9x, remaining 0:12 RBU 100.0% UBU 19.2% 4616749056/4700372992 (98.2%) @7.3x, remaining 0:08 RBU 100.0% UBU 19.2% 4650139648/4700372992 (98.9%) @7.2x, remaining 0:05 RBU 100.0% UBU 19.2% 4683038720/4700372992 (99.6%) @7.1x, remaining 0:01 RBU 100.0% UBU 19.2% :-[ [EMAIL PROTECTED] failed with SK=5h/ASC=21h/ACQ=00h]: No space left on device :-( write failed: No space left on device /dev/dvd: flushing cache /dev/dvd: stopping de-icing /dev/dvd: writing lead-out Findings of another test will be tomorrow Tomasz Dnia 31 marca 2008 16:42 "Thomas Schmitt" <[EMAIL PROTECTED]> napisał(a): > Hi, > > > The main question is why does the system in question > > discriminate DVD+RW in particular. > > That would be explainable by faulty firmware > which switches speed too early. > > But why does it work with full speed when > cdrecord is used ? > Especially with DVD+RW it is not very likely > that any SCSI command before writing > would influence the drive as observed by Tomasz. > The drive only announces two speeds. > None of them is below 6x. > So growisofs should be unable to make it run slower. > > > That's why i propose a test with cdrskin. > (Elsewise growisofs is at least as capable with > DVD as is cdrskin.) > > I forgot to propose a test with plain operating > system driver: > time dd if=/dev/zero of=/dev/hdc bs=1M count=1000 > > The measured time and the size of 1000 MiB would > allow to compute the average speed. > > > Have a nice day :) > > Thomas > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > >
Re: Low burning speed
Hi, Tomasz KÅ~Baptocz wrote: > i finally tried out cdrskin - it behaves just > like growiso, first zone ok, second zone slowly. > Growis with option "speed=6" works properly, > "speed=8" like without speed option. This strengthens the suspicion that there is a timing problem in the drive between incomming data and the rotation frequency of the media. > But what's interesting growiso+K3b and speed set > at 6x records at 3.5 - 4x, when 8x is checked - > first zone 3.5 - 4x, second 2.5 - 3x. Strange (once again). The problem seems to react very sensitively on the environment of a burn run. I assume k3b still has the option "Show Debugging Output" (or a similar one) which after a burn run reports the external commands and their message output. It would be interesting to see the effective growisofs command which was used and led to this extra low performance. > [EMAIL PROTECTED]:~$ growisofs -Z /dev/dvd=/dev/zero > ... > 212172800/4700372992 ( 4.5%) @6.0x, remaining 10:13 RBU 100.0% UBU 88.5% > 232062976/4700372992 ( 4.9%) @4.3x, remaining 10:16 RBU 100.0% UBU 96.2% > 254279680/4700372992 ( 5.4%) @4.8x, remaining 10:29 RBU 100.0% UBU 46.2% > 286949376/4700372992 ( 6.1%) @7.1x, remaining 9:59 RBU 100.0% UBU 19.2% > ... > 4683038720/4700372992 (99.6%) @7.1x, remaining 0:01 RBU 100.0% UBU 19.2% This higher speed indicates that the timing problem sits on the computer side of the suspect couple (computer versus DVD drive). In general it seems to run better in simple situations and gets worse with any additional activity which runs together with the burn. My currrent theory is that the drive does not accept new data from the computer while it is waiting for the media to rotate to the next write position. Possibly the reason for this waiting is that the drive is too optimistic about the timing and expects the computer to send the next data more quickly after the drive gets ready for receiving again. New experiments: - Retry with cdrecord. Check whether it really is burning at 8x speed by measuring the overall burning time. Please post some of the cdrecord message output. - If cdrecord reliably works with an overall throughput of (nearly) 8x, then we need to find out the difference. If you did not try growisofs running as superuser yet, then do it now. Maybe the superuser gets a better performance out of the sg driver of your Linux system. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Low burning speed
"Thomas Schmitt" <[EMAIL PROTECTED]> wrote: > New experiments: > > - Retry with cdrecord. > Check whether it really is burning at 8x speed > by measuring the overall burning time. > Please post some of the cdrecord message output. There is no need to check, cdrecord has no such problems ;-) The only known problems are with older mainboards and completely filling up DVD with 16x-18x writing. This is bacause older boards may not be able to read and deliver sustained 23 MB/s. The cdrecord DMA test at the beginning should detect this problem early. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Low burning speed
Hi, i wrote: > > - Retry with cdrecord. > > Check whether it really is burning at 8x speed Joerg Schilling wrote: > There is no need to check, cdrecord has no such problems ;-) The check shall confirm that. I had numerous occasions when it seemed that a drive-media problem was related to particular programs, but finally it turned out that this impression was caused by lucky (or unlucky) incidents. The current problem nevertheless seems to be heavily influenced by the other activities on Tomasz' computer. So it may well be about the burn programs and/or their way to communicate with the operating system. Nevertheless, it is important to make sure that the stated facts are really sustainable. One can waste a lot of time by looking for differences which do not really exist. The check with cdrecord is only half of the experiment proposal. The other half is to bring growisofs nearer to the situation which is normally given with cdrecord. I.e. the fact that cdrecord is recommended to be used setuid root. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Low burning speed
DVD+R 16x info: INQUIRY:[HL-DT-ST][DVDRAM GSA-4163B][A106] GET [CURRENT] CONFIGURATION: Mounted Media: 1Bh, DVD+R Current Write Speed: 16.0x1385=22161KB/s Write Speed #0:16.0x1385=22161KB/s Write Speed #1:16.0x1385=22160KB/s Write Speed #2:12.0x1385=16621KB/s Write Speed #3:12.0x1385=16620KB/s Write Speed #4:8.0x1385=11081KB/s Write Speed #5:8.0x1385=11080KB/s Write Speed #6:4.0x1385=5540KB/s GET [CURRENT] PERFORMANCE: Write Performance: 7.2x1385=9913KB/[EMAIL PROTECTED] -> 15.9x1385=22059KB/[EMAIL PROTECTED] 16.0x1385=22160KB/[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 Speed Descriptor#2:02/2295103 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#3:02/2295103 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#4:02/2295103 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#5:02/2295103 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#6:02/2295103 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s READ DVD STRUCTURE[#0h]: Media Book Type: 00h, DVD-ROM book [revision 0] Media ID: MCC/004 Legacy lead-out at:2295104*2KB=4700372992 READ DISC INFORMATION: Disc status: appendable Number of Sessions:2 State of Last Session: empty "Next" Track: 2 Number of Tracks: 2 READ TRACK INFORMATION[#1]: Track State: partial/complete Track Start Address: 0*2KB Free Blocks: 0*2KB Track Size:2060720*2KB READ TRACK INFORMATION[#2]: Track State: blank Track Start Address: 2062768*2KB Next Writable Address: 2062768*2KB Free Blocks: 232336*2KB Track Size:232336*2KB ROM Compatibility LBA: 266544 FABRICATED TOC: Track#1 : [EMAIL PROTECTED] Track#AA : [EMAIL PROTECTED] Multi-session Info:[EMAIL PROTECTED] READ CAPACITY: 2060720*2048=4220354560 time test: [EMAIL PROTECTED]:~$ time dd if=/dev/zero of=/dev/hdc bs=1M count=1000 1000+0 przeczytanych recordów 1000+0 zapisanych recordów skopiowane 1048576000 bajtów (1,0 GB), 98,1632 sekund, 10,7 MB/s real1m38.320s user0m0.012s sys 0m5.952s Pktcddvd not used, doesn't matter whether growiso is started as root or user. I burned some data using cdrecord+xcdroast again, the average speed was about 7.7 although it complained that dma is off. I checked it with hdparm (of course it was on), then just in case "hdparm -X udma2" and again time test, unfortunatelly no improvement. > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > >
Re: Low burning speed
Hi, > [EMAIL PROTECTED]:~$ time dd if=/dev/zero of=/dev/hdc bs=1M count=1000 > skopiowane 1048576000 bajtów (1,0 GB), 98,1632 sekund, 10,7 MB/s That's nearly 8x speed. Given that there is a short piece of 6x at the start, this is the full nominal speed to be expected. I am running out of ideas but one: scheduling priority. Try as superuser: nice -20 growisofs ...normal.slow.job... If this shows no better performance, try the same with cdrskin. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Low burning speed
DVD+R 16x info: INQUIRY:[HL-DT-ST][DVDRAM GSA-4163B][A106] GET [CURRENT] PERFORMANCE: Write Performance: 7.2x1385=9913KB/[EMAIL PROTECTED] -> 15.9x1385=22059KB/[EMAIL PROTECTED] Wow! It "says" that it will gradually increase velocity, perhaps operate at constant angular velocity? For reference. Zoning is determined mostly by unit mechanics and has lesser to do with media. Indeed, in order to provide some linear velocity disk has to be rotated faster closer to center [where recording starts]. And there is limit for how fast given motor can go. Zone boundaries reflects maximum motor spin at given radius. I basically wanted to see zone boundaries (assuming that it would be same for all media types in this unit), but it doesn't show... Oh, well... time test: [EMAIL PROTECTED]:~$ time dd if=/dev/zero of=/dev/hdc bs=1M count=1000 1000+0 przeczytanych recordów 1000+0 zapisanych recordów skopiowane 1048576000 bajtów (1,0 GB), 98,1632 sekund, 10,7 MB/s As Thomas mentioned it's essentially 8x you see. Pktcddvd not used, doesn't matter whether growiso is started as root or user. When started as root growisofs boosts its priority and instructs system to pinpoint its memory (so that it's not swapped out). I burned some data using cdrecord+xcdroast again, the average speed was about 7.7 although it complained that dma is off. I checked it with hdparm (of course it was on), then just in case "hdparm -X udma2" and again time test, unfortunatelly no improvement. It appears that your system "balances" somewhere at 8x. Or in other words slightly less than 8x is what it can deliver to the unit. Whether or not you actually get near 8x depends on combination of small factors and growisofs (as well as cdrskin) apparently ends up just below the level when unit if forced to take a lot of idle rotations and performance drops a lot. As mentioned, it seems to be specific to DVD+RW, but it's probably unit that requires a tad larger marginal for its DVD+RW recording strategy. How come just growisofs? Probably the fact that growisofs constrains itself to 32KB data transfers is one of the small factors. I mean larger transfer chunks would allow performance not to slip. But one way or another you don't want to "balance" on the edge (small factors come and go, you stay) and should concentrate on optimizing your system. Most likely it's kernel deficiency, so kernel upgrade [or downgrade] might help, but make sure recording unit is on dedicated IDE channel, double-check cabling... Meanwhile stick to -speed=6 [for all recordings to ensure you're below the edge with marginal]. A.
Re: Low burning speed
Hi, Andy Polyakov: > It appears that your system "balances" somewhere at 8x. Or in other words > slightly less than 8x is what it can deliver to the unit. My theory is slightly different. I would blame it on latency and not on throughput because Tomasz can write DVD-R or DVD+R with 8x and no obvious performance glitches. My idea is that the drive blocks on a WRITE10 from the SGIO driver for a very short while, when it misses the write position due to rotation frequency. Then it becomes ready to accept the next write, but SGIO does not react fast enough, so that again the write position is missed and again blocking occurs. This would give a decisive role to the very early speed performance switch from 6x to 8x. It would also explain why in the same LBA range nominal 6x works better than nominal 8x. One could try to verify that idea by making a small pause at about 2 GB, wait for everything to calm down, and then resume writing. In my theory, after the pause there would be full 8x throughput, because then latency would be less critical due to higher sector frequency at the outer rim of the media. The pause would be made to break the bad rythm of blocking and resuming the WRITE commands. > How come just growisofs? Probably the fact that growisofs > constrains itself to 32KB data transfers libburn once used 64 kB but a year ago i switched to 32 kB because 64 kB did not work well with the combination of SuSE 9.0, USB, CD and audio sectors. I had a similar report before from Eduard Bloch about kernel 2.6 and USB but at that time i had neither a USB drive nor a 2.6 kernel. -- To Tomasz: One could revoke that 32k change for an experiment: Currently in libburn/os-linux.h : /* ts A70523 : >32k seems not good with kernel 2.4 USB drivers and audio #define BURN_OS_TRANSPORT_BUFFER_SIZE 65536 */ #define BURN_OS_TRANSPORT_BUFFER_SIZE 32768 Experiment proposal: #define BURN_OS_TRANSPORT_BUFFER_SIZE 65536 make install and then run the test with cdrskin again. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Low burning speed
Hi, i have to amend my experiment proposal about 64 kB rather than 32 kB blocking factor. It turned out that libburn with DVD always used 32 kB in the past. So this would be untested and in worst case could lead to the need to reboot if the drive dislikes it heavily. Necessary changes would be : In libburn/os-linux.h : #define BURN_OS_TRANSPORT_BUFFER_SIZE 65536 In libburn/write.c this "32" would have to become "64" o->obs = 32*1024; /* buffer flush trigger for sector.c:get_sector() */ Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Low burning speed
To be quite sure my system doesn't cause problems related with speed i borrowed a nec writer and did some test - of course everything was ok. When i was replacing burners back i inserted plug upside down and now won't be able to do test proposed by Thomas. Thank you for cooperation, we must abandon this issue as unresolved Tomasz Dnia 2 kwietnia 2008 16:00 "Thomas Schmitt" <[EMAIL PROTECTED]> napisał(a): > Hi, > > i have to amend my experiment proposal about > 64 kB rather than 32 kB blocking factor. > It turned out that libburn with DVD always used > 32 kB in the past. > > So this would be untested and in worst case could > lead to the need to reboot if the drive dislikes > it heavily. > > > Necessary changes would be : > > In libburn/os-linux.h : > #define BURN_OS_TRANSPORT_BUFFER_SIZE 65536 > > In libburn/write.c this "32" would have to become "64" > o->obs = 32*1024; /* buffer flush trigger for sector.c:get_sector() */ > > > Have a nice day :) > > Thomas > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > >
Re: Low burning speed
Tomasz K??aptocz <[EMAIL PROTECTED]> wrote: > To be quite sure my system doesn't cause problems related with speed i > borrowed a nec writer and did some test - of course everything was ok. When i > was replacing burners back i inserted plug upside down and now won't be able > to do test proposed by Thomas. Thank you for cooperation, we must abandon > this issue as unresolved > Why don't you use cdrecord? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
