grant@torque.net
Sun, 23 Aug 1998 16:42:20 -0400 (EDT)
> > Use EPP mode if at all possible, and set the port delay to 0, to get
> > maximal performance. Also, use the "blocking" options of tar or cpio
> > to buffer your data in 16k blocks for best performance.
>
> I've been using the blocking options already. I've set 32k blocks
> though. Why 16k? 32k is the number that the mode sense 0x2a page
> returns, and seems to be the transfer size in the kernel sources.
In my tests, there was no significant improvement past 16k.
> 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.
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.
> 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 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.
--------------------------------------------------------------------------
Grant R. Guenther grant@torque.net
--------------------------------------------------------------------------
-- 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