scs@m-net.UUCP (Steve C. Simmons) (07/07/87)
We have been using tip with a VT-100 emulator on our SUN systems, and have recently found that one of our user complaints is not a problem with the emulator but a "feature" of tip. Here's the situation: We have a large number of Suns running SunOS 3.2 (UCB 4.[23]) and some large vaxes running VMS 4.5. We connect the serial ports from Sun to VAX terminal lines, run the VT emulator (henceforth called vtem) in a window, and then give the tip command to access the serial port and login to the vax. For the most part things work fine. However, when using full screen editors, it appears that tip buffers up all the incoming characters following a "clear screen" sequence until (effectively) you get into an input wait from the keyboard. At that point *all* the characters appear at once (boom). This honks off our users to no end, since at low baud rates they see "<screen clear><8-10 second pause><boom-screenfull of data>". We've tried varying all the tip parameters that looked promising, but no joy. We've also tested it tipping thru modems to UNIX III and UNIX V systems, and gotten the same results -- if you want to see it, try "tip <host>", log in, and then "vi <large file>". Therefore we doubt the problem is related to VMS or our emulator -- tipping without the emulator gives the same problem. An additional problem we have is with the propogation delay of ^S/^Q for flow control from the host. In tip, if you are reading a large file from the vax and type ^S to pause the input, at higher baud rates a hell of a lot comes thru before the stream pauses. Our questions are: 1. Do other people see the same problems (ie, is it Sun's tip or tip in general)? 2. Does anyone know of tip settings we could put into a .tiprc or /etc/remote file to fix up the unexpected buffering? 3. Can we make tip react more quickly to xon/xoff, or, alternatively, stop displaying immediately and attempt to buffer what comes in after we hit ^S but before the host stops sending? Worst case (ie, no-one has a fix for this) we'd be interested in a PD version of tip and fix it ourselves. Steve Simmons ...ihnp4!itivax!lokkur!scs "It's my computer and I'll snub who I want to."
david@sun.uucp (David DiGiacomo) (07/20/87)
In article <1390@m-net.UUCP> scs@m-net.UUCP (Steve C. Simmons) writes: >We have been using tip with a VT-100 emulator on our SUN systems, and >have recently found that one of our user complaints is not a problem >with the emulator but a "feature" of tip. >... > >For the most part things work fine. However, when using full screen editors, >it appears that tip buffers up all the incoming characters following a >"clear screen" sequence until (effectively) you get into an input wait >from the keyboard. At that point *all* the characters appear at once >(boom). This honks off our users to no end, since at low baud rates >they see "<screen clear><8-10 second pause><boom-screenfull of data>". It has nothing to do with tip. Ttysubwindows (e.g. shelltools) buffer updates to improve performance. I don't know any way to change the timeout, but if you want to see what's being written, hit ^S^Q quickly.