J Scott Berg (jsberg@indiana.edu)
Sun, 23 Aug 1998 18:10:27 -0500 (EST)
Hello Grant et al.--
On Sun, 23 Aug 1998 grant@torque.net wrote:
> > I guess I expected that my hard drive would far outclass the tape
> > drive: the machine is a 233MHz PII portable with a UDMA IDE hard
> > drive. At a few MB/s or so, I would expect there to be enough time
> > for the drive to get directory info and keep that 512KB buffer on the
> > drive filled up, at least after the first few seconds. Right now I'm
> > hearing the drive stop every couple of seconds (it should take a
> > couple minutes before the tape has to turn around, right?).
>
> Well, now you are confusing me. You said in the first mail that
> the _internal_ drive could stream from /dev/zero, but not with cpio.
> The only sense I could make of that is that you couldn't keep up.
Sorry for the confusion. The internal IDE streams whatever I do. The
external parallel streams from /dev/zero (I haven't tried for minutes
or anything--it streams longer than cpio does), but shines shoes with
cpio.
Hard drive activity is never particularly high, and my expectations
about relative speeds always led me to expect that I could transfer
data to the tape as fast as it could suck it down. My expectations
are sometimes wrong...
> The parallel drive _will_ do the shoe-shining thing. Even with
> delay set to zero in EPP-32 mode - it is hard to keep up with the tape.
> Sometimes, the firmware will "shift gears" into a slower speed to
> reduce the stopping and starting.
>
> The effective bandwidth of an EPP port is about 500 KB/s.
The tape really isn't much faster than that. It should (OK, should
isn't reality) be able to lock into the slower speed (now that I've
changed that timeout, it seems to do that after shining shoes for
quite a while, but then forgets as soon as the tape turns around (it
proceeds to shine shoes for quite a while again).
I still haven't tried setting that delay to zero; I should see what
that does for me.
Can the tape speed be set through an ATAPI call? My recollection was
that there was some sort of call related to that. I'll have to look
at the doc.
> > pt0: write DSC timeout
> > pt0: Sense key: 0, ASC: 0, ASQ: 0
> > pt0: Sense key: a, ASC: 0, ASQ: 0
> > pt0: write before command: alt=0x58 stat=0x58 err=0x100 loop=160001 phase=1
>
> Well, I can tell you what happened in general terms: the driver has
> given up on the command, but the drive is still expecting data.
> So, attempts to deliver another command fail :-( Change that timeout
> value and things should improve.
The timeout value has definitely improved things. It's been chugging
away for a half hour now without complaints. I'll try setting the
delay to zero and see what that does for my throughput.
Now that I seem to be getting some semblance of a backup, I'll try to
do some more systematic tests (e.g., see if /dev/zero will really
stream past a turnaround, see what the speed of doing the same backup
to /dev/null is, etc.).
> > The first two lines repeat several times, presumably before the
> > lockup. The last two lines repeat themselves (at about the same
> > frequency that bursts of I/O are let through) until I killed the
> > buffering process (which took a while at one line of text every 10
> > seconds). Any subsequent attempt to access the tape produces the same
> > lockup. No other obvious permanent effects, but I'll be rebooting
> > after I finish this note.
>
> Just rmmod the driver and load it again. That should reset the drive.
I suppose this is a good reason to make it a module! Generally, I've
never seen the point of making anything a module, but a tape drive
makes sense.....
Be comforted, the stupid thing doesn't work at all Windows 98.
Come to think of it, not much works right under Windows 98.
By the way, are the other mt ioctl's in the works? Most of them seem
to be just wrappers around ATAPI calls. Or is there more to it that
I'm not getting as usual...
Thanks for the help! Have fun
-Scott Berg
-- J. Scott Berg Phone: (812) 855-5465 Indiana University Cyclotron Facility FAX: (812) 855-6645 2401 Milo B. Sampson Lane email: jsberg@indiana.edu Bloomington, IN 47408-1398-- To unsubscribe, send mail to: linux-parport-request@torque.net -- -- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Wed 30 Dec 1998 - 10:18:07 EST