J Scott Berg (jsberg@indiana.edu)
Sun, 23 Aug 1998 15:17:37 -0500 (EST)
Hi Grant--
On Sun, 23 Aug 1998 grant@torque.net wrote:
> 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.
> This is a known problem with some firmware versions. The cure is to
> increase the value of PT_TMO to 3000.
I'll give this a try!
> > 3. I've done the same thing using an internal ATAPI TR4 drive, and the
> > noises it makes generally consist of long periods of whirring with
> > occasional breaks. With the dd from /dev/zero, I get a pretty
> > continuous whir. However, with the cpio backup, I get only short
> > periods of whirring (few seconds at best) interspersed with short
> > (<1s) high-pitched whirs. My suspicion of what's happening is that a
> > block of data is written, the write blocks until it's done; then
> > nothing is written while the next batch of data is read in by cpio.
>
> Actually, that's not what happens. The drive has a fairly large buffer
> on which the get and put pointers move asynchronously. The driver only
> stops writing when the buffer is full, and the tape only stops when it
> is empty. Cpio, however, has to scan the file system, and depending on
> your machine it may not be able to keep up.
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?).
A similar desktop system (PMMX-266, UDMA HD) with an internal IDE TR4
drive seems to have no difficulty keeping up: the tape only stops for
turnarounds (or at least the stops are very infrequent).
> The DSC timeouts are an unrelated effect when the driver gets too impatient
> waiting for the drive to turn around at the end of a track.
>
> > Right now I'm trying to add a buffering pipeline after cpio to see if
> > that helps. Any help or insight would be appreciated.
>
> Does the -C option help ?
It definitely helped to use it, but it doesn't completely solve the
problem (actually, i'm using --block-size for whatever crazy reason,
but it does the same thing).
> > By the way, I patched my kernel to print out the continuous transfer
> > limit--it would probably be good to have an ioctl return this (as for
> > ide-tape).
>
> Perhaps. Do you know any program that would use the information ?
Not really. It would probably be most useful in the kernel driver if
that did some buffering. In principle that's the number that the user
should give for the block size (?). Since most folks only have one tape
drive on their machine, if the kernel printed the number at boot, it
would probably suffice just to run dmesg. Since ide-tape implements
the ioctl, I suppose pt could implement the same one for consistency.
As things stand, it took a bit of doing to get the number.
And just to make things interesting, my little stdio buffering code
(just used setvbuf to set a huge buffer on the output and transferred
data in 32k blocks using fread/fwrite) successfully thrashed my
system: I foolishly didn't check for errors on fwrite, and this caused
all those DSC timeouts to be ignored. Well, my buffering code went
happily along without writing the occasional block, until my entire
system locked up, only letting a tiny burst of I/O through every
10-20 seconds. Note this was not a kernel modification--just a short
code I piped the output of cpio through. The kernel produced the
following messages:
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
pt0: Request sense before command: alt=0x58 stat=0x58 err=0x100 loop=160001 phase=1
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.
Thanks for the help and for doing the drivers! Let me know if you
have any other ideas for improving things. I'll try increasing the
timeout and see if I can pull off a backup. 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