*BSD News Article 18023


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.