Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!hc!lll-winken!scooter!neoucom!wtm
From: wtm@neoucom.UUCP (Bill Mayhew)
Newsgroups: comp.dcom.modems
Subject: Re: Telebit transfer rate problem
Summary: tty driver probably at fault
Message-ID: <1553@neoucom.UUCP>
Date: 28 Mar 89 12:11:58 GMT
References: <640@island.uu.net> <64160@pyramid.pyramid.com>
Organization: Northeastern Ohio Universities College of Medicine
Lines: 30


It has been my experience that quite a few implementations of Unix
have pretty crummy tty drivers, especially on the receive side of
the coin.  The lack of optimization is probably due to the fact
that most software engineers forget that anything other than a
human being might be typing characters in.  Most of the tty drivers
generate an CPU interrupt per character received.  With Unix this
is nasty, as it might mean that several context switches take place
for each character received.  If you've got it, run vmshow or
vmstat while uucico is running; you'll probably see the system time
is very high.

Our solution was to dig our old AT&T Unix PC out of the closet and
front-end it onto our vax.  The Unix PC manages pretty good xfers,
as it is essentially a zero user machine, whose only function is to
do uucp.  The Unix PC tty drive seems to be reasonably well written
too, which would make sense geiven that the machine is sold by a
company whose main interset is telecommunication.  We found this
fix simpler than attempting to re-do the BSD drivers on the vaxen.
The Unix PC -> Vax transfers take place at a low baud rate to avoid
shooting the load up too high on the vax.

Actually, the above fix, though seemingly arcane, is reasonable
since the current market price of a Unix PC is less than an
internet-discounted Trailblazer.

I like the idea that someone mentioned of putting a thin wire
ethernet port on a Trailbalzer.

Bill