Path: utzoo!mnetor!uunet!mfci!hsi!stevens
From: stevens@hsi.UUCP (Richard Stevens)
Newsgroups: comp.sys.att
Subject: Re: why is 3b1 screen so SLOW ?
Message-ID: <869@hsi.UUCP>
Date: 2 Mar 88 22:52:32 GMT
References: <864@hsi.UUCP> <8501@e.ms.uky.edu>
Organization: Health Systems Intl., New Haven, CT
Lines: 29
Keywords: 3b1, Telebit
Summary: cu.c

In article <8501@e.ms.uky.edu>, david@ms.uky.edu (David Herron) writes:

> um, I suggest you check a little bit into what system calls are
> available on SysV, especially one as old as what we got on
> our 7300's.  The only way you can write a terminal program on
> there is with the standard two processes, one read()ing and
> write()ing from modem -> screen, the other keyboard -> modem.

The cu process that's reading from the modem and writing to the
screen does a read() of 1 byte, followed by a write() of 1 byte.
That's where the problem is.  As Kernighan & Pike pointed out
(p. 203) this will kill you every time.  What you want to do is
read a buffer at a time (say 1024 bytes) after calling fcntl()
to make the fd non-blocking.  (I can't remember the specific fcntl
options - my S5 manuals are at home.)  If you're prepared to receive
0 bytes (and do the read system call again) then if more than
1 byte is ready, you can write that same amount to the screen.
I found this to be a big (i.e., factor of 20) win for something
like cu.  What's happening is the Telebit is passing characters
to the kernel faster than you can do a read/write of a byte-at-a-time.
It does make things a little more complicated if you want to parse
the received data checking for special sequences to do things like
save a copy of the modem data somewhere, but with modems approaching
the speed of the Telebit, you CAN'T do system calls for one byte
at a time i/o.

	Richard Stevens
	Health Systems International, New Haven, CT
           { uunet | ihnp4 } ! hsi ! stevens