wouk@alumni.colorado.edu (Arthur Wouk) (03/29/91)
this is on a 3b1 with 3.5 megs ram, 3.51a os. 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? i find it very hard to watch, by the way. i was using 4E(59) which was slower but also scrolled across and down the screen in a way that is easier on the eyes. -- arthur wouk internet: wouk@cs.colorado.edu
afc@shibaya.lonestar.org (Augustine Cano) (03/30/91)
In article <1991Mar28.171239.8337@colorado.edu> wouk@alumni.colorado.edu (Arthur Wouk) writes: >this is on a 3b1 with 3.5 megs ram, 3.51a os. > >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? I suspect that has to do with 3.51a. I'm running 3.51m and kermit5A(166) and see nothing of the sort. I remember, though, that async_main used to behave like this in the old days before 3.51m. >i find it very hard to watch, by the way. i was using 4E(59) which was >slower but also scrolled across and down the screen in a way that is >easier on the eyes. Version 4* kermits consumed lots of CPU cycles for no reason. One thing I have noticed in the latest (5A) kermits is that the OBM doesn't hang up properly when exiting with "^\ c" and then q. Andy was notified of this and is passing the bug report to the kermit development team; so no need to bother Andy any more about this... Exiting with "^\ h" and then q works. >-- >arthur wouk >internet: wouk@cs.colorado.edu -- Augustine Cano INTERNET: afc@shibaya.lonestar.org UUCP: ...!{ernest,egsner}!shibaya!afc
vince@tc.fluke.COM (Craig Johnson) (03/30/91)
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
andy@cs.caltech.edu (Andy Fyfe) (04/01/91)
In article <1991Mar29.200921.24483@shibaya.lonestar.org> afc@shibaya.lonestar.org (Augustine Cano) writes: >I have noticed in the latest (5A) kermits is that the OBM doesn't hang up >properly when exiting with "^\ c" and then q. Andy was notified of this and >is passing the bug report to the kermit development team; so no need to >bother Andy any more about this... Exiting with "^\ h" and then q works. Another alternative would be "def off hangup, quit" and use off. It's all moot anyway; edit 167 is now available on csvax. I never noticed this; the remote systems that I call drop the carrier when I log out, which hangs up the internal modem and that causes kermit to notice and return me to the kermit prompt. The other recent updates on csvax.cs.caltech.edu (anonymous ftp, directory pub/3b1) are groff (version 1.01 from 1.00) and perl (version 4.000 from 3.044). Andy Fyfe andy@cs.caltech.edu
andy@cs.caltech.edu (Andy Fyfe) (04/24/91)
for anonymous ftp on csvax.cs.caltech.edu, as pub/3b1/kermit-5A(170).Z. The problem with Hayes modems is advertised as fixed. Otherwise there are few changes from edit 169 (at least for the Unix version of kermit). Andy Fyfe andy@cs.caltech.edu