🚀 go-pugleaf

In article <94745@bu.edu> pankaj@bass.bu.edu (Pankaj Tyagi) writes:
   Currently I'm using on the PC side SLIP provided by Chameleon with
   a 8250 UART talking to a Racal-Milgo Modem V42bis. That modem is
   capable of giving sustained 14.4kbs and 38.2kbs burst. Using SLIP
   my throughput (that is counting only usable data, not counting
   headers and retransmission) is around 8kbs. which I believe is
   pretty good, given the fact that the database is not physically
   located in the same place as the terminal server but is about 250
   miles away connected to the terminal server through a router and
   leased line.

Between SPARCstation-1s connected via Telebit T3000/Worldblazers
(V.32bis/V.42/V.42bis, 38400 DTE) over long-distance lines (Columbus
to Minneapolis), running PPP with "VJ" TCP header compression, I see
FTP throughput like 2.4-2.7 Kbytes/sec for /vmunix and 2.8-3.2
Kbytes/sec for /usr/dict/words.  That's about 3 times your throughput.
Offhand, I'd point to your 8250 as a bottleneck.

   Given this how much can PPP improve performance or what value can
   it add to the whole process.

There's no performance difference between SLIP and PPP.  PPP has three
more bytes of per-packet protocol overhead, which turns a typical
5-byte telnet packet into 8 bytes, so your interactive latency is
imperceptibly and unmeasurably higher with PPP than with SLIP.  A
typical PPP MTU (maximum packet size) is 1500, while SLIP is typically
1006, so those extra three bytes could be amortized over a larger
amount of user data, but three bytes are down in the noise of 1500.

   As a side note, I have before me a recent article in CW titled
   "Remote user get TCP/IP sans LAN" which goes on to describe this
   prduct called "SupperPPP" whic is "...layered over the Microsoft
   Corp. Windows operating environment and Frontier's TCP/IP or any
   industry-standard Open System Interconnect communications
   protocols."

That's great!  Customers are asking us all the time to recommend a PPP
for that environment.  We'd do it ourselves, but we are UNIX
adherents, and not of the MS-Windows faith :-)

   This product, it seems provides TCP/IP functionality over serial
   lines and it "adds error correction, retransmission and speed to
   the older SLIP for remote TCP/IP networking..."

If Super-PPP is the IETF PPP WG's RFC-1331/1332 PPP, then it doesn't
have error correction or retransmission.  PPP has error detection, not
correction; PPP drops bad packets and relies upon upper layers (UDP or
TCP) for retransmission.

There are IETF PPP WG subcommittees working on error correction and
retransmission, but there aren't even any draft standards yet.  It's
all still research and exploratory stuff, nowhere near ready to call a
product nor a standard.

   "... speedwise PPP could translate into a tenfold improvement over
   SLIP"

Actually, that's attributed to someone from HDS, a company that
recently started shipping "its own version of PPP" with its X
terminals.  The article says they started shipping PPP "after rigorous
performance testing of PPP and SLIP," but I haven't been able to
reproduce their results.

   NOW is that really true. I mean I thought I was getting almost all
   I could bet from my POTS line using SLIP. Can it really be true
   that PPP is really that much superior to SLIP?

That's marketing hype.  Don't believe it.  They're constrained, like
everyone else, by (1) the amount of user data that must traverse the
link, and (2) current modem technology.  Since it's the same amount of
user data, and since they're presumably using the same type modem,
there's no difference between PPP and SLIP.

Actually, come to think of it, there's one way in which they might say
that a PPP implementation shows a many-fold reduction in the number of
bits that traverse the wire.  If the SLIP doesn't do RFC-1144 "VJ" TCP
header compression, and if the PPP does, then the size of a typical
transmitted telnet frame will decrease from forty-something to 8.
That's a factor of about five, but it doesn't affect throughput, only
interactive latency.  And plenty of SLIPs out there do VJ, they're
called CSLIP.  

If that's the comparison, then it's totally invalid.  If they had
compared a VJ-capable PPP with a VJ-capable SLIP, they would have seen
no performance difference at all.  It's not a difference between PPP
and SLIP, it's a difference between using VJ and not using VJ.

Sorry to rant.  PPP is subject to enough misunderstanding without
having a dose of misleading marketing hype thrown in too.