Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!netcomsv!gandrews
From: gandrews@netcom.COM (Greg Andrews)
Newsgroups: comp.dcom.modems
Subject: Re: PEP turnaround time
Summary: Oh, it's *ping* you're talking about?
Message-ID: <1991May24.060836.7247@netcom.COM>
Date: 24 May 91 06:08:36 GMT
References: <9105210700.AA14518@ucbvax.Berkeley.EDU> <1991May22.002144.2198@netcom.COM> <105588@sgi.sgi.com>
Organization: Netcom - Online Communication Services  UNIX System {408 241-9760 guest}
Lines: 68

In article <105588@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>  [vjs]
>> >Have I read that for the Telebit proprietary modulation scheme it takes
>> >about 1 second to turn the line around?
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Over clean lines the typical single-character turnaround time of PEP is
>> around 140-160 milliseconds. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>The single-character turn-around time is not what people notice.  Switching
>among packet sizes takes a long time.  For example, the ping command reports
>ICMP ECHO's over a SLIP line using PEP typically take >1.1 seconds.  If you
>turn on the speaker, you can hear the modem laboriously switching between
>7 and 18 baud (or whatever the exact numbers).
>

Well, you received a reply based on what you *said*, not what you *meant*.
Sorry about that.

Yes, an uncompressed implementation of SLIP will make PEP thrash between
different sized packets.  It's not a "baud" rate switch at all.  It's a
simple matter of packet size.

Regarding ping: Yes, ping will show long amounts of delay over a SLIP link
without the Van Jacobsen header compression.  According to the info I have,
ping usually uses a 64-byte datagram.  Then the datagram is wrapped in a
~20-byte TCP envelope and another ~20-byte SLIP envelope, for a grand total
of ~104 bytes of data.  Definitely too large to fit into a PEP short packet.
At best, the modem would simply switch up to a long packet and send it out
at ~50% efficiency (longs handle around 250 bytes on clean lines).  At worst,
the modem may have only part of the data when it samples its buffer, so it
puts that part into a short packet.  When the rest of the data appears in the
buffer, the modem puts it into the smallest packet it can.  Unfortunately,
a 100 byte SLIP packet will probably have enough left over to force the modem
to use a long packet - even less efficient now that some of the data has
already been sent in the previous short packet.

Thus the packet thrashing you hear over the speaker.  My understanding of 
compressed SLIP is that the SLIP overhead is reduced from ~40 bytes down to
~5 bytes.  That would drop a ping to around 70 bytes, which may fit better
into a pair of short packets.  It would DEFINITELY help interactive response
where the SLIP overhead would be reduced to fit inside a single short 
packet rather than two short packets.

>
>I've long thought that Telebit missed a bet by not using a more hysteresis
>in their packet/baud switching.  If they'd pick a speed and stick to it
>longer, much of the jerkiness of interactive traffic over PEP would go
>away.  This is obviously the problem with ping's over PEP.  It's the
>problem with control-L in a vi window.
>

That might help standard SLIP, where there's a significant amount of
overhead, but it is exactly the opposite of what you want for normal
interactive work.  You *DON'T* want the modems to stay in long packet
mode for your keystrokes just because they used longs to send your last
screen update.  Someone who is using standard SLIP could experiment with
forcing the modem into long packets only to see if the response gets better
by reducing the modem's packet thrashing.  (I'm just taking a shot in the
dark here - I've never used SLIP myself...yet.)


>vjs

-- 
 .------------------------------------------------------------------------.
 |  Greg Andrews   |       UUCP: {apple,amdahl,claris}!netcom!gandrews    |
 |                 |   Internet: gandrews@netcom.COM                      |
 `------------------------------------------------------------------------'