grant@torque.net
Sun, 23 Aug 1998 14:56:21 -0400 (EDT)
> 1. The first thing I noticed was an abysmally slow transfer rate.
> First, I found I needed to set my parallel port to EPP and not
> ECP. Found this by looking through the kernel source--in most
> places, HP implies that either ECP or EPP will work (if you're
> lucky you find the one obscure place where they say to use EPP).
This is a documentation bug. I'll try to get some more information on
mode selection and the delay parameter into paride.txt. In short:
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 hacked into the kernel to get the continuous transfer limit from
> the mode_sense call, which was 32K; if I use that as the block size
> for the above dd command, things seem to approach the expected
> transfer rate. There's also a 32K in pt.c, so I'm not sure if this
> is a device related success or a driver related success.
All tape drives benefit from using large blocks, but you are correct
this should be more clearly explained in the documentation.
> 2. Now, I tried a backup using cpio and that blocksize. Two things
> happen: the first is that I get a "write DSC timeout" at some point
> a little way into the backup. I though this might be a tape
> problem, but it occurred with two different tapes. I suspect this
> is realted to point 3:
This is a known problem with some firmware versions. The cure is to
increase the value of PT_TMO to 3000.
> 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.
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 ?
> 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 ?
My patched pt.c follows. Note also I changed the 128's
> to 36's in a couple of the command strings. In practice, it really
> doesn't matter, but those numbers do give the buffer size to the ATAPI
> controller, so to be safe they should be 36.
Thanks for spotting that.
--------------------------------------------------------------------------
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:06 EST