Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!spool.mu.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Subject: Re: Nethack Message-ID: <1993Jul6.193156.3584@fcom.cc.utah.edu> Sender: news@fcom.cc.utah.edu Organization: Weber State University, Ogden, UT References: <21678c$13q@klaava.Helsinki.FI> <216rcfINNj4@fstgds01.tu-graz.ac.at> <29099@ksr.com> Date: Tue, 6 Jul 93 19:31:56 GMT Lines: 49 In article <29099@ksr.com> jfw@ksr.com (John F. Woods) writes: >chmr@edvz.tu-graz.ac.at (Christoph Robitschko) writes: >>And yes, for terminal reads we'll probably check the PTE for each byte >>(on 386 or without the 486 WP bit). But terminal reads are normally >>not important for performance (who can type fastest ? 8-), > >Uh, well, I've seen uucicos that can "type" at 38.4Kbps. It would sure be >nice if this brand-spanking new 486 I have could keep up, at least on ONE >port, with my 10-year-old UNOS system with one-tenth the processing power... Augh! Charles Rivers Data Systems! Run! 8-). >>and I think someone is working on changing terminal reads to use copyout >>instead of subyte. > >That should help. Actually, it should help a *lot*. The majority of problems come from the use of subyte and a single dequeue of the input character, as if all I/O were at VMIN instead of a precheck of the read request size and the use of that size for an internal buffering. The other option whould be to check the ptdi for the buffer to be copied to and lock it down and then just push bytes into it until done (then unlock it) based on some idea of a minimal payback in number of bytes for this to be effiecient. For a G protocol packet, this would surely be worth it! Another consideration might be that it would be easier to do the lock-down with data buffers that didn't cross segment boundries, so readv would lend itself to even better block optimization than read, and perhaps the tty code (and UUCICO code) could be adjusted to take advantage. The biggest consideration, however, must be the use of subyte on the false assumption that the buffer size and VMIN size are equivalent. Thus the optimization suggested by Christoph should be first. I haven't taken a shot at a serial driver (yet ;-)), but it would seem to me that cannonical and signal processing (hardware signals, not software) are too mixed into the driver itself. I think we should be pushing toward more of an ldterm style interface so that the whole thing need not be rewritten each time. Terry Lambert terry@icarus.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.