🚀 go-pugleaf

:In article <3c5m64$584@crl10.crl.com>, Eric Penn <stupid@crl.com> wrote:
:>
:>
:>I've seen some people posting output from a program that seems to be called
:>"traceroute" that shows the routing and speed of a connaction from thier
:>host to a remote site.  But, I can't seem to find this program anywhere
:>around these parts.  Is it fiction?
:>
:>What is the best way to determine the average speed of a connection between
:>my home site (crl*.crl.com) and another site?
:>
:>-- 
:>-Eric Penn                    STUPID's three rules to life:
:> stupid@crl.com                1> Stick with what you're good at,
:>                               2> Learn from your mistakes,
:>                               3> When in doubt, act stupid!

    traceroute exists on most UNIX platforms, it basically sends a
    packet to a destination but with a truncated TTL, causing an
    intermediate site to return an ICMP packet.  The packet is
    retransmitted with a larger and larger TTL (time to live) in
    order to 'trace' all the intermediate sites a packet goes through.

    traceroute isn't perfect, especially when the route is asymetric.

    Also, routers tend to give traceroutes and pings the lowest possible
    priority.

    This makes traceroute excellent at detecting congested routers, but
    not so hot telling you how fast a network is or what the interactive
    performance is like.  Even so, the ping times are usually within 20%
    of what the interactive response would be, and most people are as 
    interested in congestion these days as they are in interactive
    response because so many backbone providers are not upgrading their
    equipment to handle demand.

    The only time when the ping time will be wildly off the mark from
    interactive performance, at least in my experience, is when you
    transit a link that performs Van-Jacobson compression... the
    compression only applies to TCP packets, not ICMP/IP packets, so
    ping/traceroute does not give you the actual itneractive response.

						-Matt

-- 
    Matthew Dillon	director, BEST Internet Communications, Inc.
		    <dillon@best.com>, <dillon@apollo.west.oic.com>
    [always include a portion of the original email in any response!]

stupid@crl.com (Eric Penn) writes:

>I've seen some people posting output from a program that seems to be called
>"traceroute" that shows the routing and speed of a connaction from thier
>host to a remote site.  But, I can't seem to find this program anywhere
>around these parts.  Is it fiction?

It certainly isn't fiction.  traceroute lists off the routers it encounters
between point A and point B.  It's available (source code) from ftp.ee.lbl.gov

>What is the best way to determine the average speed of a connection between
>my home site (crl*.crl.com) and another site?

The ping program (which should be somewhere on your system) allows you to
find how long it takes for network packets to make a round trip between
you and another site.  The newer clients (BRMH, COW, COW-lite) have a ping
window that gives you the same information updated while you're playing
netrek.  ping times of less than 100ms are very nice, but if you are
using a modem, people say that the minimum is around 300ms.  Ping also
lists the percentage of packets that don't make the round trip ("dropped
packets", "packet loss").  It also gives the average round trip time, the
standard deviation, and the minimum/maximum round trip times.

--tots

:In article <3c6bkg$9d3@gap.cco.caltech.edu>,
:Tatsuya Murase <tots@wrath.ugcs.caltech.edu> wrote:
:>stupid@crl.com (Eric Penn) writes:
:>
:>>I've seen some people posting output from a program that seems to be called
:>>"traceroute" that shows the routing and speed of a connaction from thier
:netrek.  ping times of less than 100ms are very nice, but if you are
:using a modem, people say that the minimum is around 300ms.  Ping also
:lists the percentage of packets that don't make the round trip ("dropped
:packets", "packet loss").  It also gives the average round trip time, the
:standard deviation, and the minimum/maximum round trip times.
:
:--tots

    A high speed V.34 asynchronous modem will yield on the order of 150ms ping
    time (standard ping with 56 data bytes) if you have the local
    modem<->host links running as fast as possible.

    Theoretically, you would think that a 64 byte packet on a 28.8Kbps
    link would take only 44mS round trip.  There are several factors that
    increase round trip delays.

    A reliable connection 'packetizes' data in the modem before
    modulating it, and the data is sent out over the wire in packets.
    This creates additional delay and causes burstiness.  In order to
    minimize round trip time, you want to set the local host<->modem
    link to run as fast as your computer can reliably handle.  After all,
    a local host<->modem link at 28.8Kbps would add another 44mS.  If
    the modem on the other end has a local link speed of 28.8Kbps, that's
    yet ANOTHER 44mS, yielding 44x3 = 132mS minimum theoretical round
    trip time **for a small packet**.  (note that modems not in reliable
    mode do not packetize data and may result in a quicker round-trip
    because the characters are pipelined, so the local link speed does
    not add significant delay.  However, you then do not get end-to-end
    flow control or an error-free connection).

    On the otherhand, if you run the local host<->modem link at, say, 
    115Kbps on both ends, you wind up with 44 + 2 or 46mS minimum
    round trip time.

    Portmaster's can generally go that fast, but PCs are usually
    limited in how fast you can run their serial ports reliably,
    especially in the face of Windows, OS/2, or some other 
    operating system.

    There are also other delays... compression adds delay (but reduces
    over-the-wire packet size and so may reduce the delay overall), modem
    buffering adds delay, the underlying modulation adds delay, and the
    reliable protocol packetization adds delay.

					-Matt

-- 
    Matthew Dillon	director, BEST Internet Communications, Inc.
		    <dillon@best.com>, <dillon@apollo.west.oic.com>
    [always include a portion of the original email in any response!]