;Date      16 Jan 93 00:45:05
From:      Uucp@1:125/555
To:        Tomj@1:125/111
Subject:   the latency collection...
Options:   kill-sent private 
;Status:   (read 2 times)
;INTL 1:125/111 1:125/555

From  kumr!sug.org!mis
From: mis@sug.org (Mark Seiden)
To:   tomj@fidosw.fidonet.org
Date: Fri, 15 Jan 93 16:35:17 -0500

Xref: world comp.protocols.ppp:522 comp.dcom.modems:11827
Path: world!uunet!sun-barr!male.EBay.Sun.COM!c
ronkite.Central.Sun.COM!exodus.Eng.Sun.C
OM!appserv.Eng.Sun.COM!sun!amdcad!netcomsv!wolfgang From: wolfgang@netcom.COM 
(Wolfgang Henke) Newsgroups: comp.protocols.ppp,comp.dcom.modems Subject: 
Latency: T1,56Kbit,modem (was:Re: Our experience with T3000s/PPP/KA9Q) 
Message-ID: <1992Feb14.230555.20416wolfgang@netcom.COM> Date: 14 Feb 92 
23:05:55 GMT References: <1992Feb13.083710.9253wolfgang@netcom.COM> 
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Lines: 37 

Here some more latency data, including a T1. Please excuse me if I include the
data I posted earlier again. This is only intended to facilitate a comparison
between the numbers. 

Sun----9600 bps modem---codec--a couple miles---codec-----modem-----delfin.com
 
Sun----DSU-----56 to 64 Kbit/s digital leased line-------------DSU--CALNet-pa1
 
Sun----DSU-----T1 1.34 to 1.536 Mbit/s digital leased line-----DSU-Barrnet.net

The physical distance for both 56 and T1 is a bit over 12 miles and very close
to each other.

The command used was ping -s host packetsize-8. Then I just looked at a couple 
screenfull outputs and stopped. The lowest ping time reached during this run
is recorded in the table below.
 
Packetsize        9600bps modem link      56Kbit/s        T1 ~1.5Mbit/s
 
   16               230                        29               0
   32               230                        30               0
   64               310                        40               0       
  128               400                        60               9
  256               560                       100              10       
  512               830                       130              20
 1024              1510                       350              30
 2028                  -                         -             50 
 2048                 -                       500              -
 
I could not decrease the packet size under 16, that is 8 data bytes and 8
header bytes. At 2048 total bytes the modem link data was not reliable due
to packet loss. So I did not enter a figure. The maximum data packet size to
reliably return on the T1 was 2020 bytes. I added a new row to reflect this.
 
-- 
______________________________________________________________________________
    Wolfgang Henke     wolfgang@henke.sf-bay.org       wolfgang@netcom.com

Newsgroups: comp.dcom.modems
Path: world!decwrl!netcomsv!mork!wolfgang
From: wolfgang@netcom.com (Wolfgang Henke)
Subject: DIGICOM V.32bis V.42bis fax modem: Test and Offer
Message-ID: <bqdk=kf.wolfgang@netcom.com>
Date: Wed, 06 May 92 06:13:52 GMT
Organization: Netcom


       Ever since the Digicom 9624LE+ showed the best performance in
       Vernon Schryver's recent SLIP ping tests (appended) I was interested
       in Digicom modems.

       Here are my test results of the new Digicom Systems Inc. lower priced
       Scout Plus V.32bis V.42bis fax modem, which is also based on the
       Analog Devices DSP chipset.
                             
       Data throughput:

       Scout+  to      T2500   V.32 V.42bis    compressed      1050 cps
       Scout+  to      T2500   V.32 V.42bis    uncompressed    1750 cps
       Scout+  to      T3000   V.32bis V.42bis compressed      1600 cps
       Scout+  to      T3000   V.32bis V.42bis uncompressed    1900 cps(*)
       Scout+  to      USR DS  V.32 V.42bis    compressed      1050 cps
       Scout+  to      USR DS  V.32bis V.42bis compressed      1600 cps
        
       Modem delay:

       Scout+ from Palo Alto to the Nat'l Institute of Standards time 
       service in Colorado at 1-303-494-4774 using the echo feature. The 
       one way delay is 75 msec. (The 16550 causes ~1.3 msec of this, taken 
       at 1200 baud). This number compares well with other high speed modems.

       Interactive response:

       Smooth and zippy at V.32 V.42bis (T2500) and V.32bis V.42bis (T3000)
       to SunOS on Solbourne Series 5 multiprocessor system.
       Smooth to BBS in Colorado with unknown V.32 modem.
       Smooth to BBS in Berlin, Germany (but large satellite latency,
       estimated at 500 msecs).
       Smooth and zippy to 3 different local USR DS BBS systems based on
       PCboard/DOS 3.3 and CBBS/OS2.

       The modem is based on an Analog Devices 2101 DSP chipset which performs
       at a cycle speed of ~83 nsecs. Some might translate this into 12 MIPS
       and even multiply this number to reflect the three parallel
       arithmetic processors. I do not know if this is justified.
       There are two EPROMS with 1 MB and 512 kbytes. The DTE speed was
       locked at 57600 baud for all tests. New applications with this DSP
       can be anticipated in the future I hear, direction multimedia, ISDN, 
       voicemail etc.

       The entry marked (*) was expected to have a higher data throughput
       but was limited due to a DTE speed of 19200 baud at the receiving
       modem. The Scout can initiate and respond to rate renegotiations.

       The speaker is scratchy and has no volume control besides ON, OFF and
       ON until the carrier is detected (default).

       The RJ11s do not connect through to a second line on the same RJ11
       cable (because the lines are used for PBX signaling in the 9624LE+).

       The fax software was easy to install under DOS 3.3 and tested 
       satisfactorily faxing to another fax machine across town as well as
       using MCIMail with the fax option.

       If there is enough interest I could offer these modems to readers
       of this newsgroup for $320 in a one time Usenet offer. Send email 
       if interested.

        Here again the features:

        DIGICOM Scout Plus V.32bis, V.32, V.42bis, V.42, V.22bis fax modem
        300-14400 bps data, 57600 baud DTE speed, mnp 2-5, Group 3 Fax, 
        9600 bps fax, Dosfax Lite and Winfax Lite software, Qmodem software, 
        adaptive handshake, auto line monitor and retrain, initiates and 
        answers retrain requests, 5 year warranty, internal version has 16550, 
        external version is $320 and internal $312, Compuserve coupon.


      ---------- start appended file --------------
~Newsgroups: comp.dcom.modems
~From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
~Subject: Re: SLIP Propagation Delays
Organization: Silicon Graphics, Inc.  Mountain View, CA
~Date: Mon, 16 Mar 1992 22:40:16 GMT


Enclosed are my results after testing a pair of ZyXEL with "V 4.04" EPROM's.
Their latency is much improved, but their throughput is as before.  Their
latency is strangely bimodal.


modem                                 latency                speed
  --------------------------------------------------------------------
Telebit
 T2500 to T2500                       245 msec               1200 bytes/sec
    ("9600/LAPM" (v.32) at 19.2 DTE)
        When saturated, the modems would lock up with DCD + and CTS -.

 T3000                                202 msec              >3600 bytes/sec
    ("38400/LAPM/COMP/14400")
        38.4 is not fast enough to overload the T3000's compressor with
        the repetative `ping` "data".
 ---------------------------------------------------------------------
ZyXEL
 U-1496E ("U1496E 122091")            279 msec               3100 bytes/sec
    ("38400/V32b 14400/V42b")

 U-1496E ("U1496E V 4.04")            203 or 223 msec        3100 bytes/sec
 ---------------------------------------------------------------------
Digicom Systems, Inc  (DSI)
 9624LE+                              163 msec               3550 bytes/sec
 =====================================================================

 latency: `ping remotehost` for at least 60 seconds and note the
    quickest response.

 speed: `ping -s xxxx remotehost` for at least 20 seconds, and observing
    that the delay is not steadily increasing.  The number 'xxxx' is the
    largest round number at which the modems seem to keep up.

The first test is intended to measure the latency of the modems.  The
second depends on full-duplex throughput and modem compression.  The data
in the packets has low entropy, consisting of ICMP and IP headers and
"counting bytes" (1,2,3,...).  The packets in the first test are 3+84 bytes
long (cslip framing, IP, ICMP, data).

These tests are not real modem throughput measurements.  They might almost
be similar to SLIP traffic.

The systems were running 4.3BSD-(mostly)reno TCP/IP stacks in SGI's IRIX
4.0.1 SLIP with VJ cslip.  (Cslip does not compress ICMP ECHOs.)  The MTU
was 512.

Each system used an intelligent serial board with modified firmware which
can run 4 ports each at 38.4b/s or 5 ports at about 34KBytes/sec aggregate,
measured by running several `cp bigfile /dev/ttyz` to loop-back cables.
The drivers on the serial ports add as much as 20 milliseconds of
(intentional) latency.  Timing is done with the IRIX "fast timers" turned
on.  RIP, time service, and DNS traffic is on to keep things from being
completely artificial.

The phone lines are all in the same CO.

Vernon Schryver,  vjs@sgi.com
        ---------- end of appended file ----------------
-- 
   _________________________________________________________________________
   Wolfgang Henke        wolfgang@henke.sf-bay.org       wolfgang@netcom.com



From: wolfgang@netcom.com (Wolfgang Henke)
Newsgroups: comp.dcom.modems
Subject: Re: Maximum uucp throughput over V.32bis?
Message-ID: <-ldl##+.wolfgang@netcom.com>
Date: 13 Jun 92 06:10:38 GMT
References: <1992Jun12.213638.25730@jwt.UUCP>
Organization: Netcom
Lines: 30

john@jwt.UUCP (John Temples) writes:
: keep streaming.  Is this analysis correct?  Do the latency times that
: were posted here (which were in the range of 200 ms) include the
: round-trip travel time, or only one way?

Let me answer this since I believe that Vernon Schryver, the resident latency
expert, recently moved to Colorado, away from SGI here in silicon valley.
I sure wish we could continue to enjoy his expertise.

The ping latency tests published here all used ICMP packets and measured the 
round trip time from transmitting to remote and back to the transmitting Unix 
workstation. Modems like the Digicom 9624LE+ performed very well with 
about 160 ms. Many others had times of 200 ms or more.

There is an easy way to check your modem latency even without using a Unix
workstation. Dial into the National Bureau of Standards Time Service in
Colorado and use their echo feature to measure the one way delay between you
and the time signal in Colorado. For 2400 bps modems its about 40 ms, more
for high speed modems. The V32bis Digicom Scout Plus, my favorite modem, takes 
about a 75 ms one way delay. 

So, it seems that the modems I know have a shorter round trip delay than
the number you calculated.

The NBS time service number is 1 (303) 494-4774 and uses 1200 bps.  


-- 
   _________________________________________________________________________
   Wolfgang Henke        wolfgang@henke.sf-bay.org       wolfgang@netcom.com


Path: world!uunet!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!ns-mx!isca
From: isca@icaen.uiowa.edu (Iowa Student Computer Assoc)
Newsgroups: comp.dcom.modems
Subject: Speed tests on the Supra v.32bis modem
Message-ID: <12098@ns-mx.uiowa.edu>
Date: 10 Apr 92 03:27:07 GMT
Sender: news@ns-mx.uiowa.edu
Organization: isca
Lines: 65


  I recently did some thruput tests on various modems here at the U of Iowa
using SLIP (Serial Line Internet Protocol) to give me some timing
measurements.  The results were posted to this group.  Unfortunately, the
Supra modem came in after most of the modems had been sent back.  I
did do a little testing with the Supra, and since it's the hot topic
here these days, I thought I'd post the results. 

  The bottom line of the testing was that the Supra did well on compression
but did very poorly on latency testing.  So the modem would be fine for 
downloading and general interative stuff, but not as good for things like
SLIP or X-remote.  

Modems:
  ZyXEL U-1496E
  Codex 3260 series
  USRobotics V.32bis
  NEC N9635E
  Supra FAX Modem v.32bis
  
           Ping Times (ms)
[Measures latency - lower number are better]
           
       |        Local
Remote | NEC    USR     Codex   ZyXEL
-------+-----------------------------
NEC    | 262            230     235
Codex  | 233    171     230     202
USR    |        146     179     168
Supra  |                        266


 ASCII FTP transfer rate (Kbytes/sec)
[Measures v.42bis compression - higher
numbers are better]

       |        Local
Remote | NEC    USR     Codex   ZyXEL
-------+-----------------------------
NEC    | 3.31           3.32    3.16
Codex  | 2.62   2.70    2.68    2.71
USR    |        3.29    3.32    3.34
Supra  |                        3.30

Binary FTP transfer rate (Kbytes/sec)

       |        Local
Remote | NEC    USR     Codex   ZyXEL
-------+-----------------------------
NEC    | 1.50           1.51    1.50
Codex  | 1.50   1.50    1.50    1.49
USR    |        1.49    1.50    1.53
Supra  |                        1.48

  If anyone would like info about the setup, mail me.

  - dave
--
-----------------------------------------------------------------------------
|  David Lacey                           | Try the ISCA BBS and Archives    |
|  President, Iowa Student Computer Assn | Telnet/FTP: grind.isca.uiowa.edu |
|  The University of Iowa                | telnet/rlogin in as iscabbs      |
|  David-Lacey@uiowa.edu                 | 3 GIG of disk space and growing  |
-----------------------------------------------------------------------------




Path: world!uunet!zaphod.mps.ohio-state.edu!mi
ps!news.cs.indiana.edu!umn.edu!umeecs!dip.eecs.umich.edu!dmuntz From: 
dmuntz@dip.eecs.umich.edu (Daniel A Muntz) Newsgroups: comp.dcom.modems 
Subject: Re: V.32bis modems, which one? Message-ID: 
<1992Feb6.041000.8773@zip.eecs.umich.edu> Date: 6 Feb 92 04:10:00 GMT 
References: <1992Feb04.231037.27239@ecst.csuchico.edu> 
<1992Feb6.002559.5233@celit.fps.com> <gndkp1g@sgi.sgi.com> Sender: 
news@zip.eecs.umich.edu (Mr. News) Organization: University of Michigan EECS 
Dept., Ann Arbor Lines: 12 

In article <gndkp1g@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) 
writes:
>The latency I measured for ping's over a pair of T3000's was 202 msec,
>compared to 163 msec for a pair of Digicom (DSI) 9624LE+'s.  I could not
>saturate the T3000's with only a 38.4kb/s DTE link, but could the DSI's.
>(Of course, this is a measure of compression on low entropy data.)

I've had similar results: a pair of T3000's shows ~200 msec latency while
a pair of USR DS's has ~165 msec latency.
(v.32bis v.42bis 38.4k-interface in both cases)

  -Dan Muntz
   dmuntz@dip.eecs.umich.edu

Path: world!uunet!sun-barr!ames!sgi!rhyolite.wpd.sgi.com!vjs
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.dcom.modems
Subject: Re: V.32bis modems, which one?
Message-ID: <gplbnok@sgi.sgi.com>
Date: 7 Feb 92 19:56:30 GMT
References: <1992Feb6.002559.5233@celit.fps.com> <gndkp1g@sgi.sgi.com> 
<1992Feb7.121047.26252@athena.mit.edu>
Sender: vjs@rhyolite.wpd.sgi.com
Organization: Silicon Graphics, Inc.  Mountain View, CA
Lines: 34

In article <1992Feb7.121047.26252@athena.mit.edu>, lstein@athena.mit.edu 
(Lincoln Stein) writes: > I've been following the benchmark figures for 
various modems with > interest but puzzlement. >  > What do these figures 
mean?  Specifically, what is latency, and how do > you measure it?  Under what 
circumstances does latency become the > limiting factor in the modem's 
performance? 



"Latency" in this case is how long it takes the modem to get off the dime
and do something.  I intended my measurements with `ping` to suggest the
delay between when I type a character and when it appears on the screen.
Ping is not a very good measure of that delay, because it involves an
80-byte burst of traffic, while VJ-cslip involves bursts of 5 bytes or so.
A better measure of interactive TCP/IP/SLIP latency would be a tool which
bounces single bytes off the standard echo servers.  However, ping is
already written and common.  Many people can repeat and confirm or refute
my measurements, without having to port a program.  People can try the
same test on modems I don't have, although with caution because they
won't have the same UNIX hardware and software I have.

I do not know how relevant ping latency is for dumb terminal uses of
v.32bis modems.  I doubt that a modem which does well with ping's would do
badly on single characters, but I'm not sure a modem with unimpressive ping
latency would be as bad on single characters.

Performing the ping latency measurement is trivial, after you have a SLIP
link running.  Just read the ping man page, and try it.


Vernon Schryver,    vjs@sgi.com


P.S.  Don't you just hate "followup-author" without warnings?



