Re: USB Port speeds

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

Hi,


James Finnall wrote:
> Responses below for the suggested commands.
> stream_recording seems to have nailed the issue down.

Let's see what the test results can teach us. :))

(Re-ordered sequence:)

> media reported 0 blocks for spare area and it also reported blank.
> It was new media I used for above after formating with dvd+rw-format with
> -spare=none option.

So it is not really capable of Defect Management. It cannot replace
bad blocks by blocks from the 0-sized Spare Area.


> > dd if=/dev/zero bs=1M count=1000 |  xorriso -as cdrecord -v dev=/dev/sr0 -
> This reported .9x to 1.2x

The drive still seems to checkread. This is not totally insane
because in case of bad read quality of a chunk it could still
overwrite it once more. Such a double write might well make a poor
medium readable.

But we want full speed trusting on good media quality and betting on
good luck. (If we lose, then the whole medium has to be re-written.)


> > dd if=/dev/zero bs=1M count=1000 | xorriso -as cdrecord -v dev=/dev/sr0 stream_recording=on -
> This reported 2.0x and 100% buffer fill through the operation. (@ 8.6 MB/s)

The drive obeys the urge of my WRITE(12) commands with Streaming bit
set to 1.

MMC specs do not directly promise that this disables checkreading,
but the goal of this feature is to ensure timely writing at the
expense of the risk of bad blocks staying unreplaced.


> I read the man page regarding stream_recording but not sure that I fully
> understand what the problem is exactly.

MMC mentions a feature called Stream Recording and prescribes how
it shall be controlled by the computer system ("Host").
MMC-5 4.8.4 Real-Time Stream Recording:
"The Host should use WRITE (12) command with Streaming bit set to
 one to perform the Stream recording operation. The Drive shall not
 perform the Linear Replacement operation for defective block.
 The Drives performance shall be at least 1x speed even if this
 prevents the Drive from retry or verify operation."

It turns out, that "1x speed" is interpreted as "nominal speed"
by all drives about which i have reports.
Thus no speed reducing checkreading happens during the write run.


> Since K3B wants to use growisofs does it have some ability to overcome the
> problem?

Although Andy Polyakov decided against Stream Recording in growisofs,
there is code prepared in dvd+rw-tools-7.1/growisofs_mmc.cpp :

=====================================================================
    while (1)
    {   cmd[0] = wrvfy?0x2E:0x2A;       // WRITE [AND VERIFY] (10)
        cmd[2] = (lba>>24)&0xff;        // Logical Block Addrss
        cmd[3] = (lba>>16)&0xff;
        cmd[4] = (lba>>8)&0xff;
        cmd[5] = lba&0xff;
        cmd[7] = (nbl>>8)&0xff;
        cmd[8] = nbl&0xff;
        cmd[9] = 0;
#if 0
        cmd[0] = 0xAA;                  // WRITE(12)
        cmd[2] = (lba>>24)&0xff;        // Logical Block Addrss
        cmd[3] = (lba>>16)&0xff;
        cmd[4] = (lba>>8)&0xff;
        cmd[5] = lba&0xff;
        cmd[8] = (nbl>>8)&0xff;
        cmd[9] = nbl&0xff;
        cmd[10] = 0x80;                 // "Streaming"
        cmd[11] = 0;
#endif
=====================================================================

Remove the use of WRITE(10) and the disabling #if around WRITE(12).
This should hardcode the behavior of xorriso's stream_recording.

=====================================================================
    while (1)
    {
        cmd[0] = 0xAA;                  // WRITE(12)
        cmd[2] = (lba>>24)&0xff;        // Logical Block Addrss
        cmd[3] = (lba>>16)&0xff;
        cmd[4] = (lba>>8)&0xff;
        cmd[5] = lba&0xff;
        cmd[8] = (nbl>>8)&0xff;
        cmd[9] = nbl&0xff;
        cmd[10] = 0x80;                 // "Streaming"
        cmd[11] = 0;
=====================================================================


> One of my intentions for the BD-RE is script control backups under cron.  In
> the CLI scripts I can certainly use xorriso.

Be invited. Either for wrapping the tarfiles into ISO 9660 systems
(see man xorriso) or by just burning one onto each BD medium
(see man xorrecord).
I promise help to achieve the goals of your script programming.


> However, since the backups are very large tar files then error checking
> becomes more important since tar files are essentially sequential in nature
> and error stops all read operations  Your thoughts on on reliability?

If your drive and media cannot produce flawless media in the vast
majority of tries, then Defect Management might be of help.
I.e. format your BD-RE to a moderate amount of Spare Area and do not
use Stream Recording.
The price is half nominal speed.

If your drive and media normally show no failures, then it is a
good bet to use Stream Recording.
One should check-read the result, of course. But that can be done
later and with a second drive. (Ensuring readability on the reserve
backup drive is an important part of backuping, anyway.)

There is QPXtool which can possibly judge the quality of drive
and media. The possibility depends on the particular drive.
You will in any case need a very new version. Google tells me:
"3.12.2012: QPxtool-0.7.2 released. changelog since 0.7.1.
 initial Blu-Ray media support;"

I personally have used three BD burners so far. Defect Management
did not help much with any of them. Either the medium is unreliable
or it works well. Defect Management just needs longer time to fail
at quite the same bad spot.

Your mileage may vary.


Have a nice day :)

Thomas