eto@elroy.jpl.nasa.gov (Edward T. Olsen) (06/04/91)
I am looking for advice from experienced users of high-speed modems connected to Sun SPARCStations. I must install a system at a remote site and view dynamically updated graphics under XWindows back at my laboratory. 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. I would like to achieve 19.2 kBaud. 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! Thanks in advance, Edward Olsen eto@seti.jpl.nasa.gov -- Edward T. Olsen INTERNET: eto@seti.jpl.nasa.gov (Node: 128.149.2.100) M/S: 169-506, Jet Propulsion Lab (alternate: olsen@jplrag.jpl.nasa.gov) 4800 Oak Grove Dr, Pasadena, CA 91109 (Node: 128.149.9.66 ) Phone: FTS: 792-7604 Commercial: (818)-354-7604 SPAN: 5132::olsen
bob@MorningStar.Com (Bob Sutterfield) (06/05/91)
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 <bob@morningstar.com>
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...