C1537A poor performance on SCO

[Huzzir Zakaria]

I've installed an HPC1537A/DAT24i drive on an Adaptec AIC7899 Ultra 160 SCSI controller. The OS is a SCO Openserver 5.0.6a. Installation was fine and I could use the drive to read/write with both HP supplied DDS-3 and Sony DG90 DDS tape (for compatibility reason). The problem is that when trying to tar xvf ... out data (approx 400 MB), it took between 2 to 4 hours to complete. The same behaviour can also be seen if I used the tar tvf ... to list the files. The writting to tape (tar cvf ...) command does not affected this behaviour. When I hook and older SEAGATE DDS-2 drive on the same SCSI cable, the problem was not produced thus eliminating the SCSCI cable/driver faulty. Using the command tar tvf ... to list the files on both drive shows significant speed different on the older SEAGATE drive which is faster. Suspecting the tape problem, I tried to backup and read back using the another tape but the reading part is still waaaaayyy tooooo slow....
Can anyone experienced this problem before and probably have a suggestion help me on this... I'm pretty desprate here after trying and searching for almost 2 weeks now to solve this problem...

Thanks
zhuzzir@hotmail.com

[BR19682]

Hi there.
Just a question :
anything else daisychained on the same controler ?
Rgds
Alexander M. Ermes

[Huzzir Zakaria]

Hi Alex,

At first yes, I mean that my Adaptec AIC7899 controller has a dual channel. Suspecting that's the case, I moved the tape drive to 2nd channel. Unfortunatelly, I'm still having the same problem... :(

Writting 400MB to the tape took 15-20 min however to extract back to hdisk or list the files located in near the end of 400M took nearly 3 hrs...

I've run SCO sar (System Activity Report) to analysed the possible bottle-neck on the OS configurations (buffers, cache and etc..) but it was reported OK... everythings was in order. However I do not that when tar is being executed, the drive was reported busy > 98% all the time and there's quited a number of pending requests...

Thanks for the interest...

[BR19682]

Hi there.
Next check.
Is the hardware compression set to ON ?
Because if you try to compress a tar file,
it may just slow down the transfer to tape.
Rgds
Alexander M. Ermes

[Rothery Harris]

Dear Huzzir,

I would recommend that you us the b parameter to set a blocking factor. The syntax is:
tar cvbf 30 /dev/rStp0

try using cpio and see of you still have the same problem. To back up all the files from the current directory path use:

find ./ -depth -print|cpio -ovdB >/dev/rStp0

The B option sets a blocksize of 5K which is not ideal but better than default. You will nomally see the files listed on the screen.

Rothery

[Huzzir Zakaria]

Dear Alex,
No the compression is switched of (set using tape -a 0 setcomp). Also noted that writting is OK, only when I tried to extract it back...

New update to the situation:
Found out that the jumper to set the SCSI ID was somehow has a loose metal piece. Replaced the jumper and now extraction and writting is significantly faster :). Misteriously, even with the fauly jumper, the SCSI ID was reported correctly. However, when I tried to write to a new tape, I've an error something like... "Head positioning error..." after a while of running the backup.

Thanks Rothery, I'll try your suggestion of using cpio...

Thanks a lot guys...