Bradley Rosser (b_rosser@yahoo.com)
Mon, 2 Aug 1999 04:29:47 -0700 (PDT)
I bit the bullet and bought an external HP Colorado 14GBe tape
drive two days ago - my thanks to Grant Guenther for his advice
and Cary O'Brien for his report to the list on the 14GBe that he
purchased just recently.
Running Linux 2.0.36 I followed the Parallel Port guide and
got the tape drive working with no problems. However, I've got a
few general questions which I hope people can help me with -
or guide me in the right direction:
o The pt module identifies the drive as:
HP COLORADO 14GBe, master, blocksize 512, 6471 MB
which surprises me, because I thought it was supposed to be a
7Gb drive. I'm slightly familiar with the salesmanship (i.e.
'lying') in the disk drive market, where disk drives are
creatively sized with 'kilo' dropped down to a thousand rather
than 1024, but I can't get '6471 Mb' anywhere close to '7 Mb'
without some serious 'rounding up' of several hundred megabytes.
Is this identification string correct or did a burglar come in
and steal part of my tape drive?
o I was (naively perhaps) surprised that I can't get the tape
drive to consistently stream, even with a simple dd of /dev/zero.
Cary, can you get yours to stream? Is it possible at all?
I understand that an EPP parallel port is rated about 500Kb/sec,
and the specs for the internal 14GBe have it about 1.5Mb/sec,
but I just want to confirm that no effort on my part will improve
the streaming that it currently does. At what seems to be its
lowest fallback/rate it streams for about 5 seconds before
stopping and backtracking.
o I was very surprised to note that pt.c seems to POLL the parallel
port for its I/O, and not use interrupts, which explains why
my dd process would use up to 60% of the CPU in the kernel.
I would have thought (again probabably naively?) that
a) interrupts would save a lot of CPU; and
b) interrupts would speed up parallel port I/O?
Can anyone elaborate on why pt.c was designed to poll
rather than use interrupts, or point me towards documentation?
I'm really quite curious as to why Linux, a 'real' multi-user
system, would use polling in this case.
There's a paragraph or two about interrupts versus polling in
the parport.txt document, but has the 'parallel port sharing'
(parport) project got anything to do with paride/pt/epat?
Many thanks for any advice,
Brad Rosser
b_rosser@yahoo.com
_____________________________________________________________
Do You Yahoo!?
Free instant messaging and more at http://messenger.yahoo.com
-- 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 Mon 02 Aug 1999 - 07:41:35 EDT