Re: growisofs 7.1: problem past first layer on BD-R DL

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

> I've recorded the output of -vvv -V on each.  The first two runs
> differed from growisofs in at least two aspects: 0xAA write
> command, and 64 KiB block size.

The option -tao also omitted RESERVE TRACK. (How did you watch
the SCSI output of growisofs ?)


> the certain difference is down to 64 KiB block size.

To get a confirmation, you should try a run with option -sao,
which will issue a RESERVE TRACK command.

(Chunk size 64k seems to be a prerequisite of writing without
 defect management. So stream_recording=on implies dvd_obs=64k.)


> But who knows.  I am not sure if other
> potentially relevant differences existed (e.g., in pre-write
> track setup, etc).

Not much chance except RESERVE TRACK which you avoided by -tao.
The write procedure for unformatted BD-R has not much room for
variations. I studied growisofs source code when enabling libburn
for DVD and BD. At some points i deliberately deviated after having
compared growisofs' doing with MMC specs. About half of those
deviations had to be revoked some time later.
Some of them seem to be helpful, though. :))


> Another cdrskin difference, observed in the _result_, is that
> the writing speed didn't seem to depend on speed=X setting at
> all, ranging 5.1x to 8.0x on all three burns.

libburn sends B6h SET STREAMING. But maybe the Streaming Bit in
AAh WRITE(12) overrides that and causes fukk speed.

The lower limit of 5.1x might be due to a temporary shortage of
input data (it's still nearly 20 MB/s). Did the "fifo" percentage
sink below 50 % during the write run ?
If so, then probably you will need a larger fifo size. Like
  fs=200m
which will be able to buffer 5 to 10 seconds of the drive's data
consumption.

There is a fundamental speed problem with the synchronous drive
operation that is done by libburn, and with its userspace priority.
I observe better read speed through the Linux block device
driver in comparison to libburn's READ facility. On my old 3 GHz
machine the limit for libburn seems to be with about 25 MB/s
= 5x to 6x BD. But the newer test achine (2.6 GHz) shows no
speed degradation up to 8x BD.


If you can afford another test which uses -sao and dvd_obs=64k,
then this would help to learn about the role of RESERVE TRACk
in this problem.


Have a nice day :)

Thomas