Return to BSD News archive
Xref: sserve comp.os.386bsd.bugs:1522 comp.os.linux:55617 Newsgroups: comp.os.386bsd.bugs,comp.os.linux Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!swrinde!gatech!news.byu.edu!cwis.isu.edu!fcom.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Subject: Re: Forward: QIC-80 Message-ID: <1993Sep30.233456.11034@fcom.cc.utah.edu> Sender: news@fcom.cc.utah.edu Organization: Weber State University, Ogden, UT References: <1993Sep26.203329.10048@gmd.de> Date: Thu, 30 Sep 93 23:34:56 GMT Lines: 103 In article <1993Sep26.203329.10048@gmd.de> veit@mururoa.gmd.de (Holger Veit) forwards for 71621.3022@compuserve.com who writes: > > I've seen your suggestion regarding the creation of support >for the Mitsumi CD Rom Drive, and certainly it's a wise move, I could >never understand why very popular and cheap hardware was kind of >"snubbed at" my most of the recent OS (including Unixware, NT etc.). > There's though an area that needs even more attention (in my >opinion at least), namely the support for the most popular (and cheap) >streamers. I'm sure very few can afford QIC-02 or SCSI-based tape strea- >mers, however, almost everybody I know has a Colorado or Irwin model >(that can be had for less than a _third_ of the price of a QIC-02 or >a SCSI model) (thanks to Microsoft, due to the inherent instability of >Windows it made everybody buy a streamer ;-) ). There are beta drivers that have been posted both for the Mitsumi CDROM and for the streaming floppy tape devices. The Mitsumi is a good addition to the drivers, although it contributes to "kernel bloat" in many cases, since the majority of people don't have a Mitsumi CDROM drive and thus supporting it by default in an already tight-on-space kernel can be argued to be a bad thing. The Streaming floppy tape support is an altogether different issue, and is based on some bad architectural choices by the designers of the devices. The most serious of these, the timing constraints, almost invariably end with drivers with buzz-loops in them for timing because the system clock can not be trusted to force rescheduling sufficiently quickly, given its 10mS "tick" frequency (HZ for LBOLT is 100, in explict terms). This tends to be bad; just like the original Archive/Computone tape drivers for SCO systems, actively running the tape drive kills everything else on the system as the tape driver buzz-loops so as to not miss its timing window and nothing else is allowed to run. Among other things, this results in QIC-40/80 drives being totally useless for network backup, and extremely slow because the archiving programs (like tar and cpio) are not allowed to interleave their execution with that of the tape drive -- nor is the disk driver, for that matter. DOS doesn't have a problem with this because all DOS programs, by definition, eat the machine. The cannonical soloution is to either up the LBOLT clock resoloution to 1 or 2 mS (there is a 2.5mS timing window for a particular operation) and add a real-time scheduling queue that gets exampined before all other run queues. This is the soloution taken by several UNIX variants, mostly those with real-time extensions intrinsic to the OS. This works, but is, all things considered, an unsatisfactory approach, since timing differences still must be resolved by buzz-looping at about 30% of your system (at 1mS resoloution -- HZ=1000) or 60% of your system (HZ=500). A more correct soloution is to move the lbolt clock to one of the other clocks and use the current LBOLT clock (since it is a better clock) to implement queued timer events for a high resoloution timer (the highest resoloution event being used as the discriminator). This allows the driver to schedule processing a set interval after the last set of processing, and in general will result in a vastly reduced system load. Since the TQE's are resolved in kernel space, there is not an issue of scheduling a user process at sufficient resoloution. There are two other (minor) fixes that need to be implemented to complete the "lowest overhead" scenario. The first is to allocate a minimum of a 32k buffer in kernel space (again, like the Mitsumi driver, an expensive proposition) to be used by the tape driver, and another 32k buffer as a user-to-kernel transfer area (if you are willing to block the user process in the driver, the second area is unnecessary assuming some even factor of 32k as the transfer block size). The 32k buffer is then used for a single continuous transfer without intervention; this will allow the driver to stream on an unloaded system. The next fix is related to the first, in that 32k is the minimum hunk to allow timer initiated seeks or transfers within the second timing window of 200mS. The important point is that if data is not ready, the drive can be kept happy without losing its place by issuing a seek operation on 200mS boundries; it is critical that neither the "keepalive seek" or the 2.5mS window require a particular process context to be active -- that is they should be kernel triggered events -- to minimize the impact on the scheduler code. Since this context may be swapped at the time (being that it is in an I/O wait) this provides another rationale for the second kernel transfer buffer. Finally, no matter what implementation is used, it should be noted that each vendor is not sufficiently constrained by the wording of the standard; this means that it is nearly impossible to write a single driver that operates, for instance, a Colorado Systems Jumbo 250, and some other vendors QIC-40/80 drive without rewriting, at a minimum, the initialization code. This adds a *large* amount of complexity to the project, namely because some vendors believe that other vendors may want to adopt their way of doing things (fat chance) and so won't let out programming info without non-disclosure... and since source code constitutes disclosure... you get the drift. It's exactly the Diamond dot clock problem all over again. Someone needs to hit the hardware vendors over the head and tell them we don't care who can better optimize boot code, it's how fast it runs that matters. Just because something is ubiquitous, doesn't mean that it is standard... QIC-40/80 drives are just the best example we have so far. Terry Lambert terry@icarus.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.