I always understood traceroute a different way, because of what your
seeing now. It sends out one message to the address you want to traceroute
to, then it goes back and get's the latency from you to each hop along the
way. Do you understand?
(you) -------------------------------------------------> (other person)
(you) --> (hop 1)
(you) ----> (hop 2)
(you) ------> (hop 3)
(you) --------> (hop 4)
(you) ----------> (hop 5)
(you) ------------> (hop 6)
(you) --------------> (hop 7)
(you) ----------------> (hop 8)
(you) ------------------> (hop 9)
(you) --------------------> (hop 10)
....etc
Jake
On Fri, 30 Jun 2000, Alan Mead wrote:
> Sorry for an off-topic post about network bandwidth... Everything seems
> slow lately and I want to make sure I understand some issues. Below is a
> traceroute and ping to Yahoo. Usually, Yahoo is about 200 to 300 ms
> distant. Today (right now) it appears to be about 10 times that
> distant. I tried other hosts and had similar results (although
> occasionally the time would drop for a second or two and then rise again).
>
> It seems like there are big jumps in the latencies going from hop 3 to 4
> and 4 to 5 and again in the 8,9,10 area then 11 looks pretty fast, 12-13
> slow, then Yahoo itself looks about normal.
>
> So: (1) I obviously don't fully understand traceroute; These are round
> trips between me and that node, right? So how can latencies on successive
> hops get bigger and smaller? Is this a sign of wildly unstable network
> latencies? Or are there "slow hops" and "fast hops"? Or something
> else? (2) Similarly, how could latencies to hop 12 be so large and then to
> Yahoo itself so small? Why are the latencies on hop 14 so different from
> those of the subsequent ping?
>
> Part 2: It takes me about 29 minutes to transfer some 345 megabyte files
> from one host to another over our LAN using scp. So I'm getting about 1.6
> Mb throughput, right? It's a 10Mb hubbed segment so I'm getting about 32%
> of the realistic maximum, right? We are going to replace the hub with a
> 100Mb switch so I'm expecting transfers to be 6000% faster soon.
>
> Part 3: I used scp to transfer a *whole* lot of dissertation data from a
> computer on my home LAN to a computer here at work. I started the
> transfer at 9AM. Here are some snapshots of the progress:
>
> kbytes time elapsed (Kb/s)
> -------- ---------- ------- ----------
> 103360 11:51:45 10305 10.03
> 144980 13:09:23 14963 9.69
> 154340 13:26:06 15966 9.67
> 359524 21:59:00 46740 7.69
> 412700 00:20:48 55248 7.47
>
> Did I calculate the throughput correctly? So in terms of modem speeds,
> this would be a sustained throughput of 60 kilo-baud? Which would be
> phenomenal if I had a modem but I have a cable modem at home and we have
> (only) a dedicated 128K ISDN line here at work. Does a 128K ISDN translate
> to transferring about 16 Kb/s? So I was getting about 63% of our maximum
> just before lunch and the average had dropped to only 48% towards the end
> of the transfer? If traffic to/from my work network were the cause, I
> would expect the numbers to stay pretty constant during the day and then
> jump up at night. Since the opposite seems to happen, can I conclude that
> there is a bottleneck on my cable network or in between? Or is there
> anything about scp that would cause it to progressively slow during a long
> transfer? The traffic at home passed through a Linux gateway; should
> masquerading using a Celron 400 with 128 MB RAM cause a lot of
> latency? Should I be happy with these speeds?
>
> Your thoughts, corrections, etc. are appreciated,
>
> -Alan Mead
>
> [amead@hera amead]$ traceroute www.yahoo.com
> traceroute: Warning: www.yahoo.com has multiple addresses; using 216.32.74.52
> traceroute to www.yahoo.akadns.net (216.32.74.52), 30 hops max, 38 byte packets
> 1 ipatrtr (64.5.73.1) 1.803 ms 1.843 ms 1.621 ms
> 2 its-1.soltec.net (206.148.208.4) 379.762 ms 144.834 ms 30.339 ms
> 3 gw.soltec.net (206.148.208.1) 30.347 ms 186.326 ms 191.611 ms
> 4 * * 63.238.135.69 (63.238.135.69) 58.856 ms
> 5 * chi-core-03.inet.qwest.net (205.171.20.153) 64.578 ms 333.373 ms
> 6 chi-brdr-03.inet.qwest.net (205.171.20.138) 53.553 ms 64.983
> ms 116.843 ms
> 7 ibr02-p0-1.okbr01.exodus.net (205.171.4.50) 79.681 ms 60.430
> ms 83.002 ms
> 8 * bbr01-g3-0.okbr01.exodus.net (216.34.183.65) 50.619 ms 60.761 ms
> 9 bbr02-p6-0.jrcy01.exodus.net (216.32.132.110) 80.145 ms 645.017 ms *
> 10 bbr01-p5-0.stng01.exodus.net (209.185.9.98) 1141.746 ms 997.142
> ms 462.167 ms
> 11 dcr04-g9-0.stng01.exodus.net (216.33.96.146) 226.203 ms 142.618
> ms 69.571 ms
> 12 * 216.33.98.19 (216.33.98.19) 609.612 ms 874.789 ms
> 13 216.35.210.126 (216.35.210.126) 871.602 ms 600.034 ms 286.730 ms
> 14 www3.dcx.yahoo.com (216.32.74.52) 328.424 ms 96.569 ms 127.680 ms
> [amead@hera amead]$ ping www.yahoo.com
> PING www.yahoo.akadns.net (216.32.74.50) from 64.5.73.33 : 56(84) bytes of
> data.
> 64 bytes from 216.32.74.50: icmp_seq=0 ttl=242 time=2191.2 ms
> 64 bytes from 216.32.74.50: icmp_seq=1 ttl=242 time=1659.6 ms
> 64 bytes from 216.32.74.50: icmp_seq=2 ttl=242 time=674.5 ms
> 64 bytes from 216.32.74.50: icmp_seq=3 ttl=242 time=1479.0 ms
> 64 bytes from 216.32.74.50: icmp_seq=4 ttl=242 time=1654.7 ms
> 64 bytes from 216.32.74.50: icmp_seq=5 ttl=242 time=1888.6 ms
> 64 bytes from 216.32.74.50: icmp_seq=6 ttl=242 time=1673.6 ms
> 64 bytes from 216.32.74.50: icmp_seq=7 ttl=242 time=1838.1 ms
> 64 bytes from 216.32.74.50: icmp_seq=8 ttl=242 time=1470.3 ms
> 64 bytes from 216.32.74.50: icmp_seq=9 ttl=242 time=1190.0 ms
> 64 bytes from 216.32.74.50: icmp_seq=10 ttl=242 time=381.6 ms
> 64 bytes from 216.32.74.50: icmp_seq=11 ttl=242 time=697.2 ms
>
> --- www.yahoo.akadns.net ping statistics ---
> 13 packets transmitted, 12 packets received, 7% packet loss
> round-trip min/avg/max = 381.6/1399.8/2191.2 ms
> ---
> Alan Mead, Ph.D. / Research Scientist / [EMAIL PROTECTED]
> Institute for Personality and Ability Testing
> 1801 Woodfield Dr / Savoy IL 61874 USA
> 217-352-4739 (v) / 217-352-9674 (f)
>
>
> --
> To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
> as the Subject.
>
>
Jake McHenry
[EMAIL PROTECTED]
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.