LTO speed problems

[Richard Bickers]

Because.... strangely enough, we have more accurate performance estimates from the previous tapes loaded than the current one. That's just a 'feature' of the LTO logs which we're working on for future generations.

[PSanderson]

Done cheers.

[PSanderson]

I have still not git this working - the latest test was on a shuttle PC with a fresh install of XP Pro, 1 GB memory teh only device attached is the LTOII drive and I still get 3MB/s

I have looked at the irq's and cant seea problem but I am a little unsure of myself here.

[Simon Dewhirst]

Hi there,

I am getting exactly the same problems but only 1.86mb/sec regarless of what compression/software is set/used.

I have an Adaptec 29160LM SCSI card and the drive is the only device attached to it.

I also get error 9 and moans about the configuration being narrow, yet it's set to Wide within the cards BIOS.

Disk performance is not an issue, tested with various tools including HP's own tools and can read at 27mb/sec from the drive. Also the tests run from memory in this particular case, so it doesn't make any difference.

This has been driving me mad for days now, could someone please help?

The drive is an HP Ultrium 215 which is capable of 900mb/min. 111mb/min is not acceptable and means backup routines take approximately 13 hours.

What I will also state is that the maximum sync speed in the scsi cards bios is set to ASYN and sync negotiation is set to YES/ON.

I am running the latest drivers and firmware (even though L&TT cannot detect the firmware for some reason - moans that the script cannot detect it) and have tried all sorts of different drivers for both the card and drive. Nothing has made any difference to speed.

Thanks in advance

[Richard Bickers]

I think the common theme here is termination. These drives should auto-terminate if they are in external boxes showing a green light when active.

The HBA and drive SCSI electronics re-negotiate SCSI burst rates slower if there are SCSI errors found and they go down to asynchronous if necessary. Although the LTT support ticket doesn't decode the asynchronous mode properly the words 'unknown' in that section of the ticket are a bit of a giveaway.

You could try turning active termination off and using an external terminator if there's any doubt over the drive's active termination. I assume you're using the right cabling...

If you'd like to attach a ticket to this thread I can take a look in the logs for any SCSI parity errors which would be another sign. Just save the ticket to a directory and then zip the two files inside (*.ltt and *.dat).

I think we ended up sending Paul a cable but it still didn't fix his issue. Is that right, Paul?

This is driving me nuts too...

[Simon Dewhirst]

Hi,

Thanks for the response. I think the problem may be that I have forced ASYN on the SCSI card? As far as I understand, does this not throttle the bandwidth to a maximum of 5mb/sec and the speed degrades very quickly dependant upon the length of the cable?

Granted, the cable length is not long at all and shouldn't be affected in that sense, however if the absolute maximum is 5mb/sec, would this not suggest this is where the problem resides?

When I saved the support ticket, I only received an .ltt file (no .dat). I hope this is sufficent for what is required.

I look forward to your response.

[PSanderson]

Hi Richard

No you are right this did not solve the problem and that particular project is now complete so it has had to take a back seat.

It is left as follows.

If drive is running like a dog then remove termnation if present, or terminate if it is not.

I then get to process 1 tape (about 200GB) and when I try the next tape, without fail, speed has dropped to a slow walk.

Swap the termination and I get my 60-100GB/hr.
So to get the last job done I just alternated termination between tapes.

How weird is that !!!

I may have another set of LTO's coming in soon so I may need to revisit.

[Richard Bickers]

Simon,

You probably saved the ticket from the health option which saves it in the old .ltt format. That's a bug I'm afraid... but the ticket still has what I was looking for:

|__ Drive Configuration
||__ Drive
||__ Interface
||__ SCSI Drive ID : 15
||__ SCSI Host ID : Unknown
||__ Negotiated burst data rate : Unknown
||__ DT Mode : Unknown
||__ Bus width : Unknown
||__ Clock rate : Unknown
||__ Disconnect privilege : Unknown
||__ Req/Ack Offset : 15

This looks like asynchronous mode to me. Same as what Paul was getting.

I wasn't clear from your message whether you'd set it to be asynchronous on purpose. That's not good. It should be wide and synchronous and allow the HBA and drive to negotiate the maximum rate they can both operate at - which is 80MB/S!

This is also picked up in the health/device analysis section of the ticket.

If you can change the HBA defaults back to synchronous then that has to be a good start.

Paul, thanks for getting back - your case is still a mystery. Keep in touch though I've embarassingly run out of ideas for you... Hope things go better with your new drives.

[Simon Dewhirst]

Thanks Richard, I shall try and see what happens.

If you have a look at one of the documents on Veritas's website, they suggest the following: http://seer.support.veritas.com/docs/images/234316/2940bios3.jpg

I shall take your advice in the first instance and set the "Initiate Sync Negotiation" to "Yes" and set the "Maximum Sync Transfer Rate" to "80.0"

I will post in the next day or two on how I got on and to hopefully let everyone know it was resolved.

Thanks again.

[PSanderson]

I now have another batch of LTO tapes to deal with.

I am seeing exactly the same problem.

1. Run imaging process with no active term in place, 80GB/Hr

2. Next tape, still no term - 3GB/hr

3. restart process with an active term on the drive - 80GB/Hr

4. Next tape, leave term in place - 3GB/Hr

5. Remove term and restart - 80GB/hr

I get the same scenario when using tape tools.

Still would like to sort this out...