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]
