🚀 go-pugleaf

In article <5b72239e.1bc5b@pisa.citi.umich.edu> rees@pisa.citi.umich.edu (Jim Rees) writes:
   In article <3832@randvax.rand.org>, edhall@rand.org (Ed Hall) writes:
      Telebit Worldblazers work just fine with PPP--many people use
      them for that purpose--but TurboPEP is simply not compatible
      with PPP and interactive use.

   If you use vj header compression and have a clean line, you can get
   the modem to go into micro/long mode (I think that's right) and the
   latency goes way down.  It doesn't turn the channel around in this
   mode.  I used to run that way and it was fine for interactive use,
   if you didn't have anything else going on at the same time.

PEP is an essentially half-duplex carrier.  If data needs to travel
opposite the current prevailing direction, the time required to turn
the line around between packets becomes a barrier to throughput in
both directions.  One source of opposite-direction traffic is a normal
TCP ACK packet.  I saw that effect when sending FTP data over PEP.  I
watched the modem stop the flow of data from my SPARCstation, then I
saw a brief flicker of incoming data - probably the ACKs.

However, PEP provides not only normal packets of 340 bytes, but also
small packets of 43 bytes and micro packets of 11 bytes.  Small and
Micro packets don't require the whole line to be turned around, like a
large packet does, and their fractional-line turnaround time is much
lower than if the whole line had to be turned around.  If the
opposite-direction TCP ACK could fit into a small or micro packet,
then perhaps FTP could take advantage of more forward bandwidth over
PEP.  Since typical VJ-compressed TCP ACKs and typical VJ-compressed
telnet typing echoes are well less than 11 bytes, they might be able
to fit into a micropacket.  And that seems to be the case, because I
sometimes saw the RD light flicker when the SD and CTS lights were
still lit.

But micropackets aren't assembled when 11 bytes are ready to go, and
there's no way to trigger their transmission: they are assembled and
transmitted on a clock.  And if more than 11 bytes are ready to go
when the clock ticks, a larger packet size is selected instead.  When
PEP modems train, they negotiate what sizes of packets they are to
use.  By default, they prefer large packets and micro packets.  So if
the number of ACKs that have accumulated since the last clock tick
overflows an 11 byte micro packet, a large packet is sent instead.
But that involves spending a half-second turning the entire line
around.

Between WorldBlazers running V.32bis/V.42/V.42bis, I saw 2.4-2.7
Kbytes/sec FTP throughput for /vmunix and 2.8-3.5 for /usr/dict/words.
Interactive latency was around 150ms.  Between WorldBlazers running
TurboPEP/V.42bis with the default packet sizes, I saw 2.1-2.5
Kbytes/sec for /vmunix and 3.2-3.4 for /usr/dict/words, with the
minimum interactive latency around 300ms.

But (and here we're finally getting to what may be some good news :-)
we're told by an engineer at Telebit that there's an undocumented
S-register that can tell a PEP modem to negotiate small packets rather
than micro packets.  Since there's a much higher probability of a
clock tick's worth of ACKs fitting into a 43-byte packet, there's a
much higher probability of a short packet being sent than a long
packet.  And since a short packet offers a quicker line turnaround
than a long packet, it's perhaps reasonable to hope that TurboPEP
might outpace V.32bis for FTP throughput.  And interactive latency
might even be competitive, too.  But that still doesn't necessarily
imply that TurboPEP would be useful for a line that's loaded with
bidirectional traffic.

      Date: Tue, 11 Aug 92 17:20:22 PDT
      From: mlewis@napa.Telebit.COM (Mark S. Lewis)
      
      Here's the break-down I'm told:
      
         Packet     Size        Line turn-around time     Throughput
         ------     ---         ---------------------     ----------
         Micro      11 bytes    180 ms.                   Maximum
         Small      43 bytes    250 ms.                   Almost max
         Other      340 bytes   500 ms.                   Slow
   
He suggested that we set AT~D1S500=12, which apparently disables
micropackets, but I don't know what it does about small packets.  This
changed the FTP throughput over TurboPEP to 2.1-2.5Kbytes/sec for
/vmunix (a little less), and 3.0-3.1 Kbytes/sec for /usr/dict/words (a
little more).  And it increased the interactive latency to 440-680ms,
which was the whole point of what we were trying to decrease.  This
was pretty disappointing.

I've been running these tests over a fairly good long-distance
connection, and an otherwise-idle line.  I haven't yet designed an
easily-repeatable suite of tests to find out how TurboPEP and V.32bis
will compare when carrying heavily bidirectional PPP traffic - that
is, when two or more FTP data streams are traversing the link at the
same time in opposite directions.  My gut feel, yet unsupported with
any empirical evidence, is that all the individual performances should
degrade more gracefully over V.32bis than over TurboPEP.

   But for general purpose ip use, you're usually better off with
   v.32bis.  PEP is for people stuck with obsolete, window-deprived
   software that the modem knows how to spoof (uucp or kermit, for
   example).  Or for people stuck with inferior phone lines.

Right.  That's what Telebit says, too:

      Date: Wed, 26 Aug 92 12:24:43 PDT
      From: modems@america.Telebit.COM (Telebit Support acct)
      To: a.nother@cus.to.mer
      Cc: bob@MorningStar.Com
      Subject: Re:  Any advantage to T3000 PEP over V.32bis/USR Dual Standard for PPP?
      
         Dear Telebit,
         
         I just got a pair of your new T3000 modems with TurboPep, for
         use with Morning Star PPP, and am fairly disappointed with
         the interactive and even batch performance of the TurboPep...
      
      ...the essential issue here is whether Turbo-PEP is a good
      connection method for SLIP and PPP.
      
      It's not.
      
      However, I don't think Telebit has ever said it would be.
      
      About the only situation where PEP or Turbo-PEP outperforms
      V.32bis is when the phone line quality is poor.  PEP does have
      latency, both in propagation delay and in character turnaround
      times.  The large header in uncompressed SLIP or PPP removes any
      possibility of having quick turnaround over a PEP connection, as
      Bob observes.
      
      Telebit has always recommended V.32bis (or V.32 in the days
      before V.32bis) for SLIP links, most especially ones that
      carried interactive sessions.  The latency and turnaround times
      were exactly the reasons why.  We tell people that V.32bis will
      give them faster typing response and somewhat faster FTP
      transfers, as long as they have good phone lines.  If the lines
      are bad, PEP may keep them connected where V.32bis can't.
      
      Also note that all other proprietary modulations (HST,
      Express-96, etc.)  perform just as poorly -or worse- when used
      for SLIP or PPP connections.
      
         Bob says Telebit might have an S-register to fix this -- see
         below...
      
      I'm sorry, but we don't have any magical solutions we can pull
      out of our hat to speed up SLIP/PPP over Turbo-PEP.  The basic
      nature of PEP doesn't allow certain protocols to run fast.  If a
      protocol relies on a full duplex link (or sky-high transmission
      speeds like Ethernet), then that protocol won't be efficient
      over PEP.  Uncompressed SLIP and PPP are in that category.
      
      As long as your phone lines are good, V.32bis will serve you
      best.  Proprietary modulations will not.
      
      Telebit Technical Support.