Newsgroups: comp.dcom.modems Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mstar!mstar.morningstar.com!bob From: bob@MorningStar.Com (Bob Sutterfield) Subject: Re: request for modem/xwindows advice In-Reply-To: eto@elroy.jpl.nasa.gov's message of 4 Jun 91 15:02:38 GMT Message-ID: Sender: usenet@MorningStar.COM (USENET Administrator) Reply-To: bob@MorningStar.Com (Bob Sutterfield) Organization: Morning Star Technologies References: <1991Jun4.150238.10978@elroy.jpl.nasa.gov> Date: Tue, 4 Jun 91 21:06:48 GMT Lines: 154 In article <1991Jun4.150238.10978@elroy.jpl.nasa.gov> eto@elroy.jpl.nasa.gov (Edward T. Olsen) writes: I am looking for advice from experienced users of high-speed modems connected to Sun SPARCStations. Our engineers use PPP heavily over T1600, T2500, and TB+ modems on home SPARCstations, connecting to our office network and thence to the Internet. Our connection to the Internet (via the OARnet regional) runs over a similar setup. The Protocol: I must install a system at a remote site and view dynamically updated graphics under XWindows back at my laboratory. The X Window System requires a reliable network data stream between clients (things generating graphics) and servers (things displaying dots on your workstation screen). The only ones of my acquaintance that it supports are DECnet, and TCP over IP (various ISO CONS schemes are in the works, but I'm not aware of any that are already available). Unless you are thoroughly wedded to the DECnet protocol suite for other mission requirements, or unless you're ready to wait for an entire ISO protocol suite implementation for all your hardware, I'd suggest you look at running TCP/IP. There are two common ways to carry IP traffic over serial links (e.g. async dialup modems): SLIP (the Serial Line Internet Protocol, as described in RFC 1055) and PPP (The Point to Point Protocol, as most currently described in RFCs 1171 and 1172). Unless you're hopelessly wedded to SLIP because of other mission requirements such as a need to support old hardware and software, you should run PPP. PPP is the IETF (Internet Engineering Task Force)-blessed way to do this stuff. Read the Deficiencies section of RFC1055 and the Introduction of RFC1171 for a discussion of the relative technical merits of SLIP vs PPP. Whichever you pick, you should find an implementation that incorporates Van Jacobson's scheme for TCP header compression, as described in RFC 1144. This will dramatically improve the interactive responsiveness of your network, and somewhat improve your overall throughput and application bandwith utilization efficiency as well. The lab terminal might be a Sun SPARCStation or some other microcomputer (i.e., Mac) or terminal running client software. ... Comments and caveats about protocols, specific modems, their manufacturer and cost, and what additional software or operating system configuration patches are required for efficient utilization of the Sun SPARCStation RS-232 ports is welcome! A free SLIP implementation for Suns is available via anonymous FTP from ftp.ee.lbl.gov:cslipbeta.tar.Z. Another is in bbn.com:pub/dialup2.0.tar.Z and ftp.uu.net:networking/dialupip*. A free PPP implementation for Suns is available from tut.cis.ohio-state.edu:ppp-sparc4.1.tar.Z. For IBM PCs (and perhaps Macintoshes, but I'm not sure), the current KA9Q release supports PPP and probably SLIP. Get it from thumper.bellcore.com:pub/ka9q/*. Other free implementations exist for other machinery, but these are likely to be of interest in the network you described. Several vendors have implemented SLIP and PPP. In particular, FTP Software sells them for the PC, The Wollongong Group sells them for several systems, Intercon sells them for the Macintosh, SCO sells SLIP as part of their UNIX, and Telebit has built them into dedicated router boxes. Telebit's routers and BBN's software both support "on-demand" dynamic link management, so that you only connect to the remote site when you have packets for them, and the link only stays up while it's active. The Modem: I require a high-speed modem connection with data compression and error checking (the phone line has the quality of two tin cans connected by a string) which provides a real data transfer rate of at least 9600 baud one-way. PPP and SLIP both do well enough with any modern V.32/V.42/V.42bis modem, if your lines are in any way reasonable. Don't even consider running over a modem without VJ header compression in your PPP or SLIP implementation. We use Telebit T1600s because we have a good relationship with Telebit Inc and their distributors in our region. Like everyone else, we're eagerly watching this year's crop of V.32bis/V.42/V.42bis modems, which should provide even better throughput (see below). If you must work over really, remarkably bad lines, or over satellite links, or over international connections, you might consider using a Telebit Trailblazer with PEP. Interactive responsiveness suffers some, and FTP throughput is somewhat slower than over a V.32 modem with its DTE latched at 38400, but PEP simply doesn't drop its connection in the face of line noise. I would like to achieve 19.2 kBaud. Here are the results of my informal benchmarks, as reported to a mailing list of people using the PPP implementation described above for Suns: Date: Fri, 15 Mar 91 15:19:32 -0500 From: Bob Sutterfield To: ppp-interest@poseur.JPL.NASA.GOV Subject: recent tests: throughput! I've been doing some informal throughput tests using Sun-4/60s running SunOS 4.0.3c and a 4/110 running SunOS 4.1.1. I'm running the PPP implementation as found in tut.cis.ohio-state.edu:pub/ppp, with TCP header compression enabled. I use FTP to copy a SPARC kernel, and watch it grow as it arrives. For a two-way test, I do the FTP across the line in both directions at the same time. The modems are Telebit T1600s latched to the Suns' native CPU-board serial ports at 38400bps, and a T2500 and a TB+ latched at 19200bps. The direct serial line is a 25-pin null modem ribbon cable about four feet long. I'm using CTS/RTS flow control everywhere. Between the TB+ and the T2500 I ran PEP, but all the other connections were V.32/V.42/V.42bis. Everything is configured with an MRU/MTU of 1500. The PPP process on each machine was built with the native Sun C compiler, with the default optimization level (-O2) in effect. (Any other test conditions I've forgotten to mention?) PEP yields FTP throughput of 1.3-1.5 Kbytes/sec one way. T2500-T1600 yields 1.5-1.6 Kbytes/sec one way. T1600-T1600 yields 1.7-2.8 Kbytes/sec one way. T1600-T1600 yields 1.5-2.2 Kbytes/sec both ways (12-22% degradation) direct serial line yields 3.7 Kbytes/sec one way direct serial line yields 3.6 Kbytes/sec both ways (3% degradation) The speeds reported for the modems are their overall throughput and their "gust" throughput, on those sections of the kernel that are particularly compressible. I didn't try pre-LZ-compressed data. I was impressed at the modems' ability to handle nearly the same throughput in each direction, even when being pumped both directions at once. This is an advantage of V.32 over PEP, and an indication that the T1600s have adequate internal horsepower to keep the phone line full of data, so long as they're kept well-fed. Though I haven't tested PEP both ways at once, I strongly suspect that we'd see much more than a 12-22 percent decrease in each direction. It has been suggested to me that the current implementation, with segments as STREAMS modules, might be limiting the speed. It has also been suggested that perhaps the Suns' native tty ports' UARTS are unable to keep up with the bit rate at 38400. I think that achieving an overall 3.7 Kbytes/sec application-level throughput on a nominally 38400bps bit-rate line lays those worries to rest. To the timing resolution reported by the Sun ftp(1) client, the application is seeing 79% line use efficiency, with the rest going to stop/start bits, packet framing, and other protocol overhead. That's not too shabby for IP, but might be made yet better. Code tuning in the current implementation could yield some improvement, and wholesale reimplementation as a user-space daemon might help too. I'd also like to try setting asynch serial ports at a higher bit rate that 38400, to see when the SPARCstation runs out of steam, but that will require custom hardware. We'll see...