NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/dcom/modems/12953

Text File | 1992-09-04 | 3.5 KB | 80 lines

Newsgroups: comp.dcom.modems
Path: sparky!uunet!cis.ohio-state.edu!magnus.acs.ohio-state.edu!zaphod.mps.ohio-state.edu!mstar!mstar!bob
From: [e-mail] (Bob Sutterfield)
Subject: Re: Latency Question
In-Reply-To: [e-mail]'s message of Thu, 3 Sep 1992 00: 32:50 GMT
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: volitans.morningstar.com
Organization: Morning Star Technologies
References: <[e-mail]> <[e-mail]>
    <[e-mail]>
Date: Fri, 4 Sep 1992 14:49:23 GMT
Lines: 65

In article <[e-mail]> [e-mail] (Daniel A Muntz) writes:
   Latency hasn't changed at all between my WB's after upgrading to
   5.01.  Ping settles to ~200ms (56 data bytes).

That packet is so big (~88 octets, counting ICMP headers) that it's a
better measure of in-modem data compression (V.42bis) than of
modem-induced latency, or of the responsiveness that the user feels
when typing in a telnet session that crosses the link.

To test modem-induced latency, you want the smallest packet possible.
To measure what a user feels when typing, you want to send a
single-character telnet packet, and time how long it takes for the
echo to return from the telnetd on the other end.  Happily, these two
goals coincide if the SLIP or PPP implements RFC-1144 "VJ" TCP header
compression.  A typical single-character telnet packet will cause five
octets to cross the wire if you're running CSLIP, or eight if you're
running PPP with TCP header compression.  To conduct such
measurements, we use ftp.morningstar.com:pub/tools/telnetping.c.Z.

For illustration, here's a long distance call with VJ-capable PPP
between SPARCstations over WorldBlazers (the calling end has 5.01, the
answering end is at 5.00) running V.32bis/V.42/V.42bis:

    10:31am> ping -s pike 56 100        (exchanges ~88 octets per packet)
    PING pike.morningstar.com: 56 data bytes
    16 bytes from pike.morningstar.com (137.175.2.38): icmp_seq=0. time=448. ms
    ...
    ----pike.morningstar.com PING Statistics----
    100 packets transmitted, 100 packets received, 0% packet loss
    round-trip (ms)  min/avg/max = 253/562/5043
    10:32am>

Sending a smaller chunk of data within the ICMP packet improves the
numbers, but it still leaves a lot of ICMP header overhead:

    10:32am> ping -s pike 8 100        (only ~40 octets per packet)
    PING pike.morningstar.com: 8 data bytes
    16 bytes from pike.morningstar.com (137.175.2.38): icmp_seq=0. time=261. ms
    ...
    ----pike.morningstar.com PING Statistics----
    100 packets transmitted, 100 packets received, 0% packet loss
    round-trip (ms)  min/avg/max = 221/680/5903
    10:33am>

Here are the numbers reported by several invocations of telnetping,
which uses TCP and therefore is susceptible to the efforts of VJ
header compression in reducing the overhead of the packets it
exchanges:

    10:35am> telnetping pike        (only ~8 octets per packet)
    Opening 137.175.2.38, port 23...
    ...
    min/average/max = 0.181/0.195/0.369
    min/average/max = 0.152/0.245/1.533
    min/average/max = 0.161/0.187/0.378
    min/average/max = 0.161/0.191/0.368

These interactive latencies are far better than what you see with ICMP
pings, and they better represent the type of latency that matters:
what a user feels.  It's encouraging that they're generally below the
magical 200ms perceptibility threshhold.

I'd like to know what number telnetping would report over CSLIP or
VJ-capable PPP between USR modems, but I don't have any here.  Would
anyone care to try?