dna@ballast.cs.umd.edu (Douglas N. Arnold) (05/23/89)
On May 9 I posted the following query to the comp.dcom.modems newsgroup
and the suns-at-home mailing list:
I'm about to obtain two Sun SPARCstations, which I intend to connect
via SLIP over a dialup line across a distance of five or ten miles.
I'd like to hear opinions of the best modems for this purpose. I'm
interested in peoples' experiences concerning speed, reliability,
price, availability, etc. I've heard that PEP modems don't do so
well because of the line turnaround time and I've heard that MNP
compression has trouble with SLIP packets. Can anyone verify (or
contradict)?
The replies I received follow (slightly edited).
---------------
From: JQ Johnson <JQJ@oregon.uoregon.edu>
One point of importance is that telnet traffic is very different from
NFS traffic. Telnet is typically 1 or 2 small packets in one
direction, then echo and ack. NFS is often a stream of very large
packets followed by a response. So a priori the turnaround cost for
NFS traffic will be much less than that for telnet and friends.
I've been using some Fujitsu 19.2Kb trellis leased line modems, and
find that the encoding adds about 60ms latency to the start of each
packet. They are full duplex, but the latency translates into longer
RTT.
---------------
From: weiser.pa@Xerox.COM (Mark Weiser)
I use a pair of V.32 9600 baud modems from Codex. They work fine.
Avoid modem with compression (MNP), these do not work well with
SLIP.
---------------
From: Vaughan Pratt <pratt@cs.stanford.edu>
I use slip extensively over trailblazers running at close to 18K
(line is clean and short). The echo performance is *miserable*
compared to a direct line at 9.6K. If you type a burst of
characters, the first character is echoed a second later, then the
remaining characters are echoed another second later. It is
distractingly painful to use slip for interactive work.
Some of my delay I think can be attributed to going through a line
concentrator at the other end. Timing the round trip delay of
echoing single characters without slip, comparing a trailblazer to a
Supra 2400 baud modem, it appears that when the trailblazer is used
the delay roughly doubles.
---------------
From: Sergei A. Gourevitch <asg@space.mit.edu>
I can vouch for the fact that Trailblazer plus modems don't do SLIP
well. I don't have any reports on which modems do well.
---------------
From: watmath!cs.AthabascaU.CA!lyndon@uunet.UU.NET (Lyndon Nerenberg)
Your best bet is a *fully* compliant V.32 (ie 9600 FULL DUPLEX BOTH
DIRECTIONS AT THE SAME TIME) modem. I know the Hayes doesn't cut it.
I haven't tried the Telebit T2500 yet. The T1000/2000 will work
although the bac channel delays are noticeable. The version 6 PROMs
for the TB's will have onboard SLIP support which will cure that
problem.
---------------
From: Greg Earle <earle@mahendo.Jpl.Nasa.Gov>
I think I can speak fairly to this; I had my Sun-3/160M at home for
about 8 months ... (^:
(1) First of all, you will need a robust SunOS 4.0.3 SLIP
implementation. I would advise looking in
~ftp/pub/Sun_Patch_tapes_et_al. on this machine:
elroy.JPL.NASA.GOV (128.149.1.100)
and grab the SLIP distribution from there. This is because it fixes
a couple of crucial bugs in Rayan Zachariessen's implementation, and
it also adds support for LCK..cua# UUCP/tip-style lockfiles (if you
have a SLIP link up and you/someone tries to use tip(1) without a
lock file, it wreaks havoc on the SLIP link - trust me). I have also
added a (crude) version of a dialer program, that will call the other
end up, and prompt for the user account and password to be fed to the
other end (uses getpass() so these names are not echoed; enhances
security a little). All in all, it's a slightly more robust version
than the one you can get from AI.Toronto.EDU.
(2) I have been using this version over a Telebit TrailBlazer Plus
link to the aforementioned machine, elroy.JPL.NASA.GOV. I should
mention that elroy is a poor old Sun-2/170 running SunOS 4.0.1, and
it is a main mail/Usenet relay for JPL as well as being the secondary
name server for the JPL domain to boot - so a lot of the time, it is
VERY loaded and extremely slow. That said, I can say this: the best
ping(8) turnaround times I can get on this connection, merely calling
within the JPL phone system, is around 1.1 seconds (i.e., 1100
msec.). Remember, this is with 2 TB+'s at each end of the line.
To contrast, there is another SLIP link here at JPL, a link which
connects an Encore Annex terminal server with SLIP capability, to a
Sun which is located in Anaheim CA, about 35 miles away. The nature
of this link, on the other hand, is 2 synchronous modems, talking
over a 9600-baud dedicated leased line. At each end, there are Black
Box converters which switch from Synch to Asynch; the Sun end is
plugged into the standard CPU serial port. Not sure about the Encore
end; presumed similar. In this case, I was able to ping the remote
end of that link from a machine on the same net as the Encore, and
was getting consistent turnaround times of 0.3 seconds (i.e., 300
msec.) per packet. So, it seems that even allowing for a factor to
creep in (i.e., remote machine overloading due to wimpy old CPU), it
seems that the Asynch-Synch leased line method gains a factor of at
least 3 in throughput over the Telebit-based method. One thing which
we have not tried yet is to try connecting between my machine and
elroy at 2400 baud instead, and then see what the ping turnaround
times are. We suspect that they won't be much different/worse, and
suspect that the non-V.32 nature of the Telebits (we have TB+'s, not
T2500's remember) is what is causing the line turnaround slowdowns.
FTP's between the two machines are usually running around 800
bytes/sec.
-------------------
Thanks to all who responded. I would welcome comments from anyone
else who has experience using SLIP with modems.
-- Doug Arnold (dna@emmy.umd.edu)mhyman@hsfmsh.UUCP (Marco S. Hyman) (05/23/89)
In article <17691@mimsy.UUCP> dna@emmy.umd.edu (Douglas N. Arnold) writes: > --------------- > From: watmath!cs.AthabascaU.CA!lyndon@uunet.UU.NET (Lyndon Nerenberg) > > Your best bet is a *fully* compliant V.32 (ie 9600 FULL DUPLEX BOTH > DIRECTIONS AT THE SAME TIME) modem. I know the Hayes doesn't cut it. Hayes makes two 9600 bps modems. The V-Series Smartmodem 9600 is its proprietary, half duplex with fast turnaround. That one will not cut it for SLIP. However, the Smartmodem 9600 is a ``*fully* compliant V.32'' and should work as well as any other V.32 modem. --marc (I work for Hayes, but am not allowed to speak for them) -- //Marco S. Hyman //UUCP: ...!sun!sfsun!hsfmsh!mhyman //Domain: sfsun!hsfmsh!mhyman@sun.com
henry@utzoo.uucp (Henry Spencer) (05/24/89)
In article <17691@mimsy.UUCP> dna@emmy.umd.edu (Douglas N. Arnold) writes: > I use slip extensively over trailblazers running at close to 18K > (line is clean and short). The echo performance is *miserable* > compared to a direct line at 9.6K... One major problem here is that a one-character TCP/IP packet is too big to fit in the TB's reverse-path packets. If you attended San Diego Usenix and used the terminal room, its Internet connection was via Trailblazer, and it worked fine... thanks to Van Jacobson's header-compression code, which shrinks things down enough. Unfortunately, I don't think Van's code is generally available at the moment. -- Van Allen, adj: pertaining to | Henry Spencer at U of Toronto Zoology deadly hazards to spaceflight. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
dyer@spdcc.COM (Steve Dyer) (05/24/89)
In article <1989May23.173557.1790@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >One major problem here is that a one-character TCP/IP packet is too big >to fit in the TB's reverse-path packets. If you attended San Diego Usenix >and used the terminal room, its Internet connection was via Trailblazer, >and it worked fine... Well, whenever I had a choice between the SLIP lines and direct connects via the other Telebits, I ended up choosing the Telebit dialouts. You see, I didn't enjoy sitting in front of a screen which stopped echoing 45 seconds ago. Perhaps the environment had too many variables to sort out all the miscellaneous effects (routing, muxing many sessions over SLIP, etc.), but I did not leave San Diego with a warm fuzzy feeling about SLIP and Trailblazers, header compression or not. -- Steve Dyer dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer dyer@arktouros.mit.edu
henry@utzoo.uucp (Henry Spencer) (05/24/89)
In article <3351@ursa-major.SPDCC.COM> dyer@ursa-major.spdcc.COM (Steve Dyer) writes: >>... If you attended San Diego Usenix >>and used the terminal room, its Internet connection was via Trailblazer, >>and it worked fine... > >Well, whenever I had a choice between the SLIP lines and direct connects >via the other Telebits, I ended up choosing the Telebit dialouts. You see, >I didn't enjoy sitting in front of a screen which stopped echoing 45 seconds >ago... Worked fine when I tried it. Maybe I was lucky and got un-busy times. -- Van Allen, adj: pertaining to | Henry Spencer at U of Toronto Zoology deadly hazards to spaceflight. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
mshiels@tmsoft.uucp (Michael A. Shiels) (05/25/89)
If small backchannels hurts SLIP then wouldn't full duplex V32 modems work a lot better?
grr@cbmvax.UUCP (George Robbins) (05/26/89)
In article <1989May25.015027.7319@tmsoft.uucp> mshiels@tmsoft.UUCP (Michael A. Shiels) writes: > > If small backchannels hurts SLIP then wouldn't full duplex V32 modems work > a lot better? Obviously! Full duplex V.32 would be ideal for SLIP at 9600 baud. However, given a modem that understands SLIP packets and optimizes for this, you could have 9600->19200 buad in direction of the main data flow and whatever is needed to the less demanding direction. A 1.5x or better improvement in communications speed is probably worthwhile, especially in interactive situations. On the other hand, a non-V.32 modem that doesn't understand slip and plays adaptive half-duplex/back channel games, may give lousey performance since it doesn't understand packet boundries or acknowledgment. In this case the USR HST asymetrical back channel might work better than a Telebit and might give performance similar to a V.32 modem on a lightly loaded link. On a fully loaded link with similar volumes of data going in both directions, you'd need something that actually delivers an aggregate throughput of greater than baud to beat the V.32 modem (assuming the V.32 modem is getting 19.2K). At present, I don't have any slip connections, and lots of UUCP and dial-in connections, so the question is somewhat academic. I did order a pair of the T2500 modems to *play* with, along with a pile of T1000's and TB+'s to *work* with. 8-) Time will tell. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)