(SLIP and PPP discussions really belong in comp.protocols.ppp, but
since there were a few points of error and confusion in the responses
you collected, I thought I'd offer some (hopefully gentle) corrections
in the sun-managers forum.)
From: mike@iotek.ns.CA (Michael A. Thompson)
Date: Fri, 28 Feb 1992 10:19:18 GMT
My own interpertation of the resposes is that PPP is the way to
go...
You may also find some useful information in the paper I presented at
the Sun User Group conference last December. You can print your own
copy from ftp.uu.net:vendor/MorningStar/papers/sug91-cheapIP.ps.Z.
Kevin Sheehan's response:
This question (and summary) came out recently. For your amusement.
From: fourx!odi.com!benson
Subject: PPP and friends, summary
For sun's, there's a PD PPP available on uunet.
It's not in the public domain, but it is freely available. A more
recent version is in merit.edu:pub/ppp/pppd-1.01beta.tar.Z.
Tim Miller's response:
PPP is a superset of SLIP and I here a replacement for it.
PPP provides a superset of SLIP's functions, but the bits it puts on
the wire are neither upward compatible nor interoperable. Either both
ends must talk SLIP, or both ends must talk PPP. Yes, PPP is a
response to SLIP's deficiencies, and has rendered it obsolete. It's a
product of the Internet Engineering Task Force's Point-to-Point
Protocol Working Group, a real live Internet Standards-Track Protocol.
Bob Sutterfield's response:
(*Blush* I really didn't intend for you to include our spec sheet in
your posted summary! I beg the list's indulgence: we weren't out for
free advertising, and I tried to provide useful information besides
tooting our own horn.)
Paul Lind's response:
I use a hardware/software box from Livingston Enterprises called
a portmaster... has SLIP protocol built-in.
They'll soon be shipping with PPP support, too.
NOTE: Two Portmasters running at 38.4kBaud with T3000s or other
V.32bis modems can get effective throughputs of nearly 30kBaud.
Sun serial ports do not RTS/CTS correctly, forcing me to limit
the Sun serial port to 19.2kBaud.
We run PPP over Sun serial ports at their full 38400, with RTS/CTS
flow control as best the Sun can manage (it respects the modem's
request to slow down, but can't request that the modem slow down).
The console reports an occasional "zs1: silo overflow" but that
doesn't affect performance observably. FCS errors are rare.
An interactive session (ie, rlogin) is a little slower than
normal serial dialup with tip or something, because of the
tcp/ip overhead. I understand that there is a new protocol
called PPP which reduces this overhead.
If your SLIP or PPP doesn't implement RFC-1144 "VJ" TCP header
compression, then you're transmitting a lot of redundant bytes across
the wire for each keystroke and its echo. This increases latency and
hurts responsiveness. VJ can be done with either SLIP or PPP, or any
other packet framing scheme you might run across. If your SLIP does
VJ it's often called "CSLIP", and it won't interoperate with a non-VJ
SLIP. If your PPP does VJ it's called "a useful PPP", and it will
interoperate with a non-VJ PPP just fine, though you won't feel the
improved responsiveness because all those redundant protocol overhead
bytes will still be there. PPP peers negotiate (at connection
establishment time) whether they'll use VJ for this particular link.
From: wfs@cli.com (Bill Schelter)
Subject: slip , ppp
Date: Sun, 1 Mar 1992 19:29:41 GMT
I thought I would add my two cents worth lest slip be pronounced
dead prematurely by the ppp advocates. Note that various
manufacturers such as HP and IBM include slip support as a standard
part of their UNIX operating systems. Also companies like telesys
and cisco supply excellent slip software for their hardware.
SLIP's not quite dead yet, because a lot of people still use it. Good
PPP implementations have only become available in the past year or
two. If you must talk to a box that only does SLIP, then of course
SLIP is the only way to go until the box maker catches up and starts
shipping PPP, or until a hacker does it for free, or a 3rd-party
commercial vendor does it for cash. For a new installation, if you
have your choice, you should use PPP if you can.
PERFORMANCE:
===========
I have been using a microcom QX/4232 bis modem which connects at
14,500 The terminal ports are set at 38,400.
ftp transfer of ascii files runs at about 2400 char/second
16 bytes round-trip (ms) min/avg/max = 129/145/160
56 bytes round-trip (ms) min/avg/max = 192/209/244
[modem settings atn4,at%c1,ata0,at-k2 ]
That's about right for a V.32bis modem. I assume you've enabled V.42
error correction and V.42bis compression, right?
The ftp time should give an indication of refresh speed of screens
under emacs, and the ping time indicate the interactive rate for
echoing typing.
Please see my articles <BOB.92Feb7171055@volitans.MorningStar.Com> and
<BOB.92Feb21205930@volitans.MorningStar.Com> in comp.dcom.modems and
comp.protocols.ppp for a discussion of throughput and latency under
various conditions. ICMP Echo-Responses (pings) aren't necessarily a
good way to simulate a typist, because they aren't subject to TCP
header compression or to interactive packet priority management.
The public slip software does give higher priority to interactive
traffic, so it is possible to still do things while ftping a large
file, but it does slow things down.
My measurements show that VJ's "TCP fast queue" scheme (as implemented
in ftp.ee.lbl.gov:cslipbeta.tar.Z) does indeed yield a slight
improvement in interactive latency, but that the improvement is
greatly overshadowed by the effects of async dialup modems' typical
buffering and compression latency.
From: siedelbe@atd.ucar.EDU (Gregory M. Siedelberg)
Subject: Re: slip , ppp
Date: Tue, 3 Mar 1992 21:30:49 GMT
I am having a tough time resolving the figures you give here. You
say that you are making a 14.5 k baud connection, but you are
getting 2400 characters/ per/second performance in file transfers,
which roughly translates to 24 k baud. I know that there are
compression routines built in that enhance performance, but I
didn't know that they worked this well.
Using V.42bis in your modem can yield a theoretical maximum of 4x
compression. You might see that rate if you're using tip, and
cat(1)ing a file full of "A"s. In the real world, you'll see
something less than that.
Also I have found that ping and ftp do not give reliable stats,
depending on the machine involved and the direction of the ftp, ie.
outgoing sends report the time the data is written to the socket,
but not necessarily the real transit time. If you have taken all
this into account and still think that your slip performs this
well, I would like to know more, but maybe this should move over to
comp.dcom.modems.
Please see the articles I cited above, which include a discussion of
my measurement methodology, and pointers to the source so you can
reproduce the numbers if you like.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:38 CDT