Newsgroups: comp.sys.3b1
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!uw-beaver!fluke!vince
From: vince@tc.fluke.COM (Craig Johnson)
Subject: Re: Kermit 5A(166) is very jerky
Message-ID: <1991Mar29.204224.2923@tc.fluke.COM>
Summary: It's all in how you buffer reads and writes.
Keywords: 3B1, Kermit
Organization: John Fluke Mfg. Co., Inc., Everett, WA
References: <1991Mar28.171239.8337@colorado.edu>
Date: Fri, 29 Mar 91 20:42:24 GMT

In article <1991Mar28.171239.8337@colorado.edu>, wouk@alumni.colorado.edu (Arthur Wouk) writes:
> 
> i just picked up kermit-5A(166) from csvax as andy posted the other
> day, and installed it. i get a very jerky screen display as though
> a batch of data is sent to the video in a burst followed by a
> slight pause, then the next burst. is this common to all 3b1
> implementations, or are there some parameters to twiddle?

Older versions of kermit don't try to do any buffering in connect mode.
This results in a read call and a write call for each byte transferred
from the port to the screen -- very inefficient.  In this mode, there
is so much system overhead, the throughput to the console is terrible,
something less than 4800 CPS, and more likely about 2400 CPS.  And don't
even consider doing anything else compute intensive at the same time.

From your description, I'd assume that your new kermit is buffering
about 8 or 16 characters at a time.  This can result in rather ragged
looking displays.  If you could see it at a higher baud rate, it would
probably look OK.  At 1200 baud it'll look crappy.

If you have copies of the sources you can fix this yourself.  I suspect
kermit is not making use of "Non-Canonical Mode Input Processing" to its
best ability.  I've written a "cu" -type program where I set up the
serial port thusly,
                                        /* Setup port characteristics */
    ioctl(portd,TCGETA,&port_raw);
    port_raw.c_cflag = baud | CS8 | CREAD | clocal;
    port_raw.c_iflag = IXOFF;
    port_raw.c_oflag = 0;
    port_raw.c_lflag = ECHOK;
    port_raw.c_cc[VMIN] = 1;
    port_raw.c_cc[VTIME] = 1;
    ioctl(portd,TCSETA,&port_raw);

The important thing here is the values of VMIN and VTIME.  Set this way,
a read returns after .1 second as soon as there is at least one character
received (see termio (4 or 7?) for the full explanation).  At 1200 baud
this will return with just 1 or two characters.  But at higher baud rates,
more characters can be accumulated in a 1/10 of a second.  The process
that you set up to read the port and write to the console runs in a loop
that looks like this,
                                        /* Loop forever */
        while (n = read(portd,buf,bufsiz))
            write(1,buf,n);             /* Copy from port to stdout */

In my program I let bufsiz default to 8, but can set it at will to any
size upto 512 bytes (mostly for testing the throughput with different
buffer sizes).  Regardless of whether 1 byte, 8 bytes, or 512 bytes are
read, whatever gets read gets written to the console in one shot.
Buffered this way, processing is efficient, and the display is much
smoother.

Alternatively, you might try buffering reads and then writing a single
character at a time (perhaps even with timing between writes).  This
won't be as efficient, but should yield the smoothest possible
display.

---
	Craig V. Johnson			...!fluke!vince
	John Fluke Mfg. Co.				or
	Everett, WA				vince@tc.fluke.com