VMS Poor SDLT performance

[Tim Nelson]

Thanks for all the input.

I am still doing some testing by upping the quotas.

Ran into another problem which I will put in a different thread. ( Run/uic= does not start process as other user ).

[Uwe Zessin]

Jan,
a HSV100 or HSV110 controller has two ports and can have up to 2048 outstanding I/Os per port. But as far as I can tell OpenVMS will only use one path and the SCSI device driver will not create such a deep I/O queue anyway.

[Tom O'Toole]

Rob,

Unless I'm mistaken, removing /crc will remove BACKUP's ability to determine that a block is in error, thus greatly limiting the usefulness of redundancy groups specified with /group.

As for the original posters performance problem, if your cpu is close to 100%, and backup is the main user, you're not going to be able to significantly improve performance no matter how you fiddle with quotas.

Specifying /nocrc WILL greatly reduce BACKUP's cpu consumption, and you should test with this just to verify that CPU is your bottleneck (your throughput should go way up with /nocrc if this is the case). However, you should not trust your production backups to /nocrc, and instead consider why so much CPU is being used by backup.

Most VMS systems which support a SAN should be able to drive a single SDLT at full speed without running out of CPU. Please tell us the other details of your configuration. Thanks.

[Uwe Zessin]

Of course you are right, Tom.

Let me repeat what I have already written above:
""You can try to limit the CPU load by using /NOCRC/GROUP=0, but that is only good for testing and not a serious backup, because it will turn off end-to-end checking and remove redundancies from the save-set.""

[Jan van den Ende]

Tom, Uwe,

In the old days I would have blindly agreed 100%.

But now, in the days of SCSI....

Way back when, at a previous customer, there was the need to restore a backup tape 10 years old.
After locating a tape-unit still able to read 800 bpi reels (!), I read the backup tape.
Surprisingly, it was CPU-bound, and took quite long.
The final message explained that: 33000-some recoverable errors, and some unhappy operator who had to clean the tapeunit from most of the tapes' magnetite.
THAT is what Backup with full recovery functionality is intended to do for you, ... if you use DSA tape systems.
Now on SCSI: ONE SINGLE parity error, and SCSI forbids reading on.

Antonio will know exactly what I mean when I state that THAT is the reason SCSI is pronounced "scuzi": that is the reply in Italian if you want any recovery.

In the days of TK50 and TK70, there DID also exist DSSI devices (slow, but DSA compliant), so, IF tou had a tape with a parity error, your local DEC would read the tape for you (usually just ONE recoverable error!), and write it to another one.
I am not aware of the same being possible with any DLT II, III, or IV system.

So Tom, Uwe, anybody else, if I am too pessimistic because of ignorance, please educate me: WHAT is the use of /crc if backing up to tape? It is GREAT, but you cannot use it..

Jan

[Uwe Zessin]

It has nothing to do with 'SCSI'. It is a function of the tape drive firmware if it does not let you go past an unrecoverable spot. You could also have seen this on a DSSI-based DLT tape drive (TF85, TF86, ...).

Recoverability has nothing to do with a tape drive being DSA compliant (you talk about DSSI and CI-attached drives, right?). I have also seen BACKUP recovering errors on a Massbus-attached tape drive (TU77 or TU78, I don't recall). How does BACKUP do it? It creates redundant data similar to RAID-5!


I know that many people say that todays tape drives do lots of self-correction to cover tape errors and do not let you get past an unrecoverable spot. I still suggest to use /CRC, because it is an end-to-end check on the whole data path from the CPU to the bits on the tape. What happens if BACKUP creates a corrupted save-set? I have seen BACKUP doing that - the CRC detected it.

I am open about using /GROUP=0, but I will continue to use /CRC.

[Jan van den Ende]

Uwe,

I concur.
I never really encountered situations in which the crr overhead was a reason NOT to use it, and, maybe just because of old habit, I keep using it.
But my previous statement stands: i NEVER was able to read past (even a single) parity error on any SCSI tape drive. All the others (Q-BUS. CI etc; no Massbuss experience though) simply tarnsfered it to the OS, kinda "DUNNO, can you make anything of that?", and then, of cource BACKUP could.
But if you don't get any bits out of the drive past the parity error??
About DSSI TF8x: include them into my list of "non-SCSI drives for the tape".
DO such drives also exist for the current tape generations? If yes, Hallelujah!! Tell me about it, and I will somehow get them past the budget-guards.
(would make me happy about NOT doing without crc)

Jan

[Tom O'Toole]

Uwe,

If you use /crc/group=0, what does that get you? If /crc detects a bad block, you have no XOR block with which to recover the bad block.

[Uwe Zessin]

Tom,
when I wrote "I am open about using /GROUP=0", I meant somebody has to present some arguments _for_ using it. Thank you for the counter-argument ;-)

[Antoniov.]

I'm with Jan on SCSI; with old TK50 or TK70 we could restore data, slowly but we could.
Now, DAT tapes doesn't feel me safe.
For my own I prefer default /CRC/GROUP.

Antonio Vigliotti
P.S.
SCSI is read in italian as scuzi and sound like sorry!