DLT4000 Adaptec 2920C tape streaming question - Hardware

This is a discussion on DLT4000 Adaptec 2920C tape streaming question - Hardware ; Anybody care to hazard a guess why an old slow DLT4000 tape drive wouldn't stream continuously on a more or less modern linux system? Mandriva 10.2 Quantum DLT4000 Adaptec 2920C I'm testing a couple of Quantum DLT4000 tape drives to ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: DLT4000 Adaptec 2920C tape streaming question

  1. DLT4000 Adaptec 2920C tape streaming question

    Anybody care to hazard a guess why an old slow DLT4000 tape drive
    wouldn't stream continuously on a more or less modern linux system?

    Mandriva 10.2
    Quantum DLT4000
    Adaptec 2920C

    I'm testing a couple of Quantum DLT4000 tape drives to make sure they
    still work. They have been sitting unused for quite a while.
    A 4 year old PC (Athlon XP 2000+) was pressed into duty and a scavenged
    2920C SCSI card installed. After doing:

    urpmi mt-st
    modprobe aic7xxxx

    I could see the tape device and write and read to it. There were no
    errors, but it just wouldn't stream very well. The 2920C is supposed to
    do 10Mb/sec, the tape is the only device on the SCSI chain, it is
    terminated, and the PC can easily push 1Gb/sec through memory. So why
    shouldn't it stream since the tape drive can only accept 1.5Mb/sec?
    Seems like the system should have no trouble whatsoever pushing that
    piddling amount of data out to the tape drive. For instance both of these:

    dd if=/dev/zero of=/dev/nst0 bs=1024 count=1000000
    dd if=/dev/zero of=/dev/nst0 bs=10240 count=100000

    scrubbed like crazy with about a 4 second stream before the tape
    stopped and repositioned. I tried a second DLT4000 drive and it
    did the same thing. Note, even though the tape wasn't streaming
    well there were no read or write errors - some large files were saved,
    copied back, and diff'd with no errors found.

    The PC dual boots, so XP was booted and the freeware "Turbo Tape 2006"
    installed. That software streamed much, much better than did linux.
    All tests were on a IIIXT cartridge with compression disabled on the
    drive, and a 411 Mb folder as the backup subject. TT2006 with "soft
    compression" wrote 1.11 Mb/sec with the occasional stall, and with no
    compression TT2006 wrote at 1.36 Mb/sec with so few stalls that
    I didn't see one occur. (I wasn't watching it the whole time.) When
    used in verify mode there were definitely no stalls.

    So, what's up on the linux system to cause the stalls? Is there some
    bug in the aic7xxx driver, for instance, writing to the drive in small
    blocks?

    Thanks,

    David Mathog

  2. Re: DLT4000 Adaptec 2920C tape streaming question

    On 2006-12-14, David Mathog wrote:

    > Anybody care to hazard a guess why an old slow DLT4000 tape drive
    > wouldn't stream continuously on a more or less modern linux system?
    >
    > Mandriva 10.2
    > Quantum DLT4000
    > Adaptec 2920C
    >
    > I'm testing a couple of Quantum DLT4000 tape drives to make sure they
    > still work. They have been sitting unused for quite a while.
    > A 4 year old PC (Athlon XP 2000+) was pressed into duty and a scavenged
    > 2920C SCSI card installed. After doing:
    >
    > urpmi mt-st
    > modprobe aic7xxxx
    >
    > I could see the tape device and write and read to it. There were no
    > errors, but it just wouldn't stream very well. The 2920C is supposed to
    > do 10Mb/sec, the tape is the only device on the SCSI chain, it is
    > terminated, and the PC can easily push 1Gb/sec through memory. So why
    > shouldn't it stream since the tape drive can only accept 1.5Mb/sec?
    > Seems like the system should have no trouble whatsoever pushing that
    > piddling amount of data out to the tape drive. For instance both of these:
    >
    > dd if=/dev/zero of=/dev/nst0 bs=1024 count=1000000
    > dd if=/dev/zero of=/dev/nst0 bs=10240 count=100000
    >
    > scrubbed like crazy with about a 4 second stream before the tape
    > stopped and repositioned. I tried a second DLT4000 drive and it
    > did the same thing. Note, even though the tape wasn't streaming
    > well there were no read or write errors - some large files were saved,
    > copied back, and diff'd with no errors found.
    >
    > The PC dual boots, so XP was booted and the freeware "Turbo Tape 2006"
    > installed. That software streamed much, much better than did linux.
    > All tests were on a IIIXT cartridge with compression disabled on the
    > drive, and a 411 Mb folder as the backup subject. TT2006 with "soft
    > compression" wrote 1.11 Mb/sec with the occasional stall, and with no
    > compression TT2006 wrote at 1.36 Mb/sec with so few stalls that
    > I didn't see one occur. (I wasn't watching it the whole time.) When
    > used in verify mode there were definitely no stalls.
    >
    > So, what's up on the linux system to cause the stalls? Is there some
    > bug in the aic7xxx driver, for instance, writing to the drive in small
    > blocks?


    I'm not sure why you're having this problem. I have three DLT drives
    attached to one of my linux machines:

    Host: scsi0 Channel: 00 Id: 03 Lun: 00
    Vendor: DEC Model: TZ88 (C) DEC Rev: CD50
    Type: Sequential-Access ANSI SCSI revision: 02
    Host: scsi0 Channel: 00 Id: 04 Lun: 00
    Vendor: DEC Model: DLT2000 15/30 GB Rev: 840B
    Type: Sequential-Access ANSI SCSI revision: 02
    Host: scsi0 Channel: 00 Id: 05 Lun: 00
    Vendor: Quantum Model: DLT4000 Rev: CD55
    Type: Sequential-Access ANSI SCSI revision: 02

    All three are on the same HBA (Adaptec-2940), and all three stream well
    at the same time. The machine is nothing special -- an old dual PIII-600
    system with 756MB RAM.

    Perhaps the problem is not linux, or the driver but dd? I use "star" to
    write my tapes and it sets up a fifo for optimum streaming. dd is a
    pretty primitive tool in comparison.


    --

    John (john@os2.dhs.org)

  3. Re: DLT4000 Adaptec 2920C tape streaming question

    John Thompson wrote:

    > On 2006-12-14, David Mathog wrote:
    >
    >> Anybody care to hazard a guess why an old slow DLT4000 tape drive
    >> wouldn't stream continuously on a more or less modern linux system?
    >>
    >> Mandriva 10.2
    >> Quantum DLT4000
    >> Adaptec 2920C
    >>
    >> I'm testing a couple of Quantum DLT4000 tape drives to make sure they
    >> still work. They have been sitting unused for quite a while.
    >> A 4 year old PC (Athlon XP 2000+) was pressed into duty and a scavenged
    >> 2920C SCSI card installed. After doing:
    >>
    >> urpmi mt-st
    >> modprobe aic7xxxx
    >>
    >> I could see the tape device and write and read to it. There were no
    >> errors, but it just wouldn't stream very well. The 2920C is supposed to
    >> do 10Mb/sec, the tape is the only device on the SCSI chain, it is
    >> terminated, and the PC can easily push 1Gb/sec through memory. So why
    >> shouldn't it stream since the tape drive can only accept 1.5Mb/sec?
    >> Seems like the system should have no trouble whatsoever pushing that
    >> piddling amount of data out to the tape drive. For instance both of
    >> these:
    >>
    >> dd if=/dev/zero of=/dev/nst0 bs=1024 count=1000000
    >> dd if=/dev/zero of=/dev/nst0 bs=10240 count=100000
    >>
    >> scrubbed like crazy with about a 4 second stream before the tape
    >> stopped and repositioned. I tried a second DLT4000 drive and it
    >> did the same thing. Note, even though the tape wasn't streaming
    >> well there were no read or write errors - some large files were saved,
    >> copied back, and diff'd with no errors found.
    >>
    >> The PC dual boots, so XP was booted and the freeware "Turbo Tape 2006"
    >> installed. That software streamed much, much better than did linux.
    >> All tests were on a IIIXT cartridge with compression disabled on the
    >> drive, and a 411 Mb folder as the backup subject. TT2006 with "soft
    >> compression" wrote 1.11 Mb/sec with the occasional stall, and with no
    >> compression TT2006 wrote at 1.36 Mb/sec with so few stalls that
    >> I didn't see one occur. (I wasn't watching it the whole time.) When
    >> used in verify mode there were definitely no stalls.
    >>
    >> So, what's up on the linux system to cause the stalls? Is there some
    >> bug in the aic7xxx driver, for instance, writing to the drive in small
    >> blocks?

    >
    > I'm not sure why you're having this problem. I have three DLT drives
    > attached to one of my linux machines:
    >
    > Host: scsi0 Channel: 00 Id: 03 Lun: 00
    > Vendor: DEC Model: TZ88 (C) DEC Rev: CD50
    > Type: Sequential-Access ANSI SCSI revision: 02
    > Host: scsi0 Channel: 00 Id: 04 Lun: 00
    > Vendor: DEC Model: DLT2000 15/30 GB Rev: 840B
    > Type: Sequential-Access ANSI SCSI revision: 02
    > Host: scsi0 Channel: 00 Id: 05 Lun: 00
    > Vendor: Quantum Model: DLT4000 Rev: CD55
    > Type: Sequential-Access ANSI SCSI revision: 02
    >
    > All three are on the same HBA (Adaptec-2940), and all three stream well
    > at the same time. The machine is nothing special -- an old dual PIII-600
    > system with 756MB RAM.
    >
    > Perhaps the problem is not linux, or the driver but dd? I use "star" to
    > write my tapes and it sets up a fifo for optimum streaming. dd is a
    > pretty primitive tool in comparison.
    >
    >



    At a late quick look it sounds like the diffference is 2920 vs 2940. You
    might try picking up a 2940 (about $30 US) comparing.

    --
    JosephKK
    Gegen dummheit kampfen die Gotter Selbst, vergebens.**
    --Schiller

+ Reply to Thread