[PARPORT] General questions re HP Colorado 14Gbe external tape drive

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

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