home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / bsd / 4401 < prev    next >
Encoding:
Text File  |  1992-08-18  |  1.9 KB  |  41 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!caen!umeecs!dip.eecs.umich.edu!dmuntz
  3. From: dmuntz@dip.eecs.umich.edu (Daniel A Muntz)
  4. Subject: Re: 386BSD QIC-02 Driver with Wangtek 5150PK is sloooooow
  5. Message-ID: <1992Aug19.051745.16119@zip.eecs.umich.edu>
  6. Sender: news@zip.eecs.umich.edu (Mr. News)
  7. Organization: University of Michigan EECS Dept., Ann Arbor
  8. References: <1992Aug17.191318.8853@hotb.sub.org>
  9. Date: Wed, 19 Aug 1992 05:17:45 GMT
  10. Lines: 29
  11.  
  12. In article <1992Aug17.191318.8853@hotb.sub.org> thomas@hotb.sub.org (Thomas Brettinger) writes:
  13. >Hi.
  14. >I got 386BSD running on a noname sx, 4 Meg Ram, a 100M Conner Disk, WD
  15. >Elite and a Wangtek 5150PK QIC-02 Streamer.
  16. >
  17. >The system runs fine, but the tape driver is incredibly slow. I looked
  18. >at the source and saw, that it's using 512 byte blocks... Oh well.
  19.  
  20. The problem isn't the 512-byte blocks, per se, but that the controller doesn't
  21. receive data quickly enough to allow the drive to stream properly.  You can
  22. get some performance improvement by buffering data in the driver and polling
  23. the controller instead of waiting for interrupts and timeouts.  Perhaps
  24. someone could comment on why so many interrupts seem to get lost.  I've
  25. hacked wt.c to do buffering and polling to make the qic-02 drives usable, but
  26. this isn't really the "right" solution.  A couple of thoughts:
  27.  
  28.   Track down why interrupts are being lost so the driver can by purely
  29.   interrupt driven (I'm not sure this would help).  It seems that the
  30.   drive streams properly when interrupts are received, but loses it when
  31.   it frequently has to fall back on the timeout to make up for lost interrupts.
  32.  
  33.   Rewrite the driver and part of subr_vnops.c (I think) to allow the driver
  34.   to pull data bufs down instead of waiting for requests to read/write.
  35.   This along with polling should allow the drive to stream.
  36.  
  37. I'm sporadically working on these things and would appreciate any feedback.
  38.  
  39.   -Dan
  40.  
  41.