Date: Thu, 9 Jul 92 14:37:18 EST From: Dwight D. McKay (The Moderator) Reply-To: Suns-at-Home@orchestra.ecn.purdue.edu Subject: Suns-at-Home Digest V5 #27 To: Suns-at-Home-List Suns-at-Home Digest Thu, 9 Jul 92 Volume 5 : Issue 27 Today's Topics: PPP, T1600, and interactive delays Suns-at-Home Digest V5 #26 [really: wiretap] +--------------------------------------------------------------------+ | Submissions: suns-at-home \ @orchestra.ecn.purdue.edu | | Requests: suns-at-home-request > -- or -- | | Archives: suns-at-home-archives / ...rutgers!pur-ee!... | +--------------------------------------------------------------------+ ---------------------------------------------------------------------- Date: Mon, 29 Jun 92 12:08:37 EDT From: "Dan Franklin" Subject: PPP, T1600, and interactive delays To: suns-at-home@orchestra.ecn.purdue.edu When I use PPP, I am seeing very high delays for interactive traffic (echoing each character I type over an rlogin): 160-200 msec. As the Van Jacobson paper says, this kind of delay is unsuitable for getting one's characters echoed; it makes using PPP very frustrating. So I usually just "tip" to the remote machine and do most of my work that way, then use PPP to test the X application I'm working on, but I'd like to run PPP all the time. I don't understand where the delay is coming from. There's a SPARCstation and Telebit T1600 at each end (ELC at one end, 4/60 at the other), running at 9600 bps on the phone line, 38400 on the serial lines, data compression enabled (though disabling it seemed not to help). Using an oscilloscope, I found that delays inside the SPARCstation at each end were small (measuring transitions between RD and TD at the connector). Using a dumb terminal with a "show-control-characters" mode, I verified that VJ compression is doing its thing (7 or 9 characters sent for each character I type). Subtracting out the turnaround delay at the remote end (about 30 msec), the time it ought to take to transmit and receive 9 characters at 9600 bps, and even subtracting out time for the characters to go over the 38400 serial links at each end (which shouldn't matter since I'd expect the modem to start transmitting the first character before it receives the last one), I am still seeing about 100 msec of unaccounted-for total delay from the time the packet leaves the TD pin at the local SPARCstation to the time its RD pin sees the echo coming back. It really looks like the modems themselves are delaying before they send the packets. But using tip, I see no delays on individual characters. This implies to me that the T1600, when it sees some number of characters on its serial line, decides to delay a bit in case some more come in. If I knew the policy, I could introduce controlled delays between characters to avoid triggering it. I called Telebit several times and had a frustrating conversation with them; they could neither confirm nor deny that T1600s have any kind of delay policy. I also sent mail to someone from Telebit who works with PPP, who never replied. Are other people seeing this problem? Does anyone know what's going on inside the modems? The only "help" I got from Telebit was that someone there understood "from the net" that non-Telebit modems "generally worked better with PPP", which certainly made me feel good :-). Looking for any help or advice, Dan Franklin ------------------------------ Date: Mon, 29 Jun 92 21:14:42 PDT From: zurna!sinan@sunup.West.Sun.COM (Sinan Karasu) Subject: Suns-at-Home Digest V5 #26 To: sunup!ecn.purdue.edu!Suns-at-Home@sunup.West.Sun.COM >> Date: Mon, 15 Jun 92 22:09:05 PDT >> From: zurna!sinan@sunup.West.Sun.COM (Sinan Karasu) >> Subject: Suns-at-Home Digest V5 #24 [really About Sun3/60, slip, etc] >> I understand that wiretap is much better than slip. >What's wiretap? I've never heard of it. Is it another means of >encapsulating IP datagrams over serial lines? see the following man page ---------cut here--------------------------- .\" WIRETAP man page .TH WIRETAP 1 "19 October 1989" .SH NAME wiretap \- provides access to remote X11/NeWS clients across a serial interface .SH SYNOPSIS .B wiretap [ .B \-f .I ttydevice ] [ .B \-s .I string ] [ .I remote_client args .\|.\|. ] .SH DESCRIPTION Wiretap is an X11/NeWS client that multiplexes remote clients across a serial interface. It starts off like ``tip'' by providing an .SM ASCII connection to a serial device. After logging in to a remote host, the user must start the .I sxnews-helper process in order to start multiplexing X11/NeWS clients across the single serial interface. After .I sxnews-helper starts, the line is switched to packet mode and .I wiretap kicks off a terminal emulator client on the remote side of the connection. >From the terminal emulator running on the remote host, other remote clients can be started. .LP Wiretap will run with the standard OpenWindows 1.0 X11/NeWS server, or a NeWS-only or X-only server. .LP In ASCII mode, you can exit wiretap by typing <~><.>, that is: a carriage return followed by a tilde and a period. .SH OPTIONS .TP .B \-f Use the next argument as the .I "tty device" instead of the default device, .I /dev/ttya . If you're using a dialup line, be sure to use the "cua" device and not the "ttyd" device, e.g., use .I "-f /dev/cua0" and not .I "-f /dev/ttyd0" . Note that the user must have read and write permissions on the specified device. .TP .B \-s Use the next argument as the string to send out the serial interface upon startup. Typically, this will be a dialing command to a modem. .TP .I ". . ." Trailing arguments are used as the name and arguments for a remote client application to be started upon switching the line to packet mode. By default, if NeWS is running on the local host, the command .I "psterm -f -t vt100 -li 24" is spawned on the remote host. If NeWS is not running on the local host, the command .I "xterm -sl 250 -s -j -sb -geometry 80x24" is spawned on the remote host. .SH FILES .LP None. .SH DIAGNOSTICS .LP Exits if RS232 line cannot be opened. .SH "SEE ALSO" .BR sxnews (1), .BR sxnews-helper (1) .LP .SH BUGS .LP When using an ALM board for the serial interface, the underlying protocol requires SunOS 4.0.3 on the machine with the ALM due to a kernel bug. .LP The terminal emulator in which .I wiretap is started can't be used until the last remote client exits. .LP This should be integrated into .I tip so that modem hunting and file locking all work together properly. ------------------------------ End of Suns-at-Home Digest ******************************