Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel!munnari.oz.au!uunet!caen!umeecs!dip.eecs.umich.edu!dmuntz From: dmuntz@dip.eecs.umich.edu (Daniel A Muntz) Subject: Re: 386BSD QIC-02 Driver with Wangtek 5150PK is sloooooow Message-ID: <1992Aug19.051745.16119@zip.eecs.umich.edu> Sender: news@zip.eecs.umich.edu (Mr. News) Organization: University of Michigan EECS Dept., Ann Arbor References: <1992Aug17.191318.8853@hotb.sub.org> Date: Wed, 19 Aug 1992 05:17:45 GMT Lines: 29 In article <1992Aug17.191318.8853@hotb.sub.org> thomas@hotb.sub.org (Thomas Brettinger) writes: >Hi. >I got 386BSD running on a noname sx, 4 Meg Ram, a 100M Conner Disk, WD >Elite and a Wangtek 5150PK QIC-02 Streamer. > >The system runs fine, but the tape driver is incredibly slow. I looked >at the source and saw, that it's using 512 byte blocks... Oh well. The problem isn't the 512-byte blocks, per se, but that the controller doesn't receive data quickly enough to allow the drive to stream properly. You can get some performance improvement by buffering data in the driver and polling the controller instead of waiting for interrupts and timeouts. Perhaps someone could comment on why so many interrupts seem to get lost. I've hacked wt.c to do buffering and polling to make the qic-02 drives usable, but this isn't really the "right" solution. A couple of thoughts: Track down why interrupts are being lost so the driver can by purely interrupt driven (I'm not sure this would help). It seems that the drive streams properly when interrupts are received, but loses it when it frequently has to fall back on the timeout to make up for lost interrupts. Rewrite the driver and part of subr_vnops.c (I think) to allow the driver to pull data bufs down instead of waiting for requests to read/write. This along with polling should allow the drive to stream. I'm sporadically working on these things and would appreciate any feedback. -Dan