I've been trying to figure out why the first ping that I send somewhere is always slow the first time, then every subsequent time it is significantly better (the first hop is really fast; it's the first ping that is slow). I found a source that told me that the first ping has to look up the appropriate address in the ARP table of the router, but how long is this supposed to take? My first pings run 300-500 msecs, then subsequent ones are usually under 100, depending on circumstances. Why is this not illustrated in any of the examples I've seen? Do I have an odd setup? Thanks! I'm on a cable modem that I just got set up with AT&T Broadband in Seattle.

I've seen this occasionally on lower bandwidth connections. If this always happens when you start Ping Plotter and trace to a target (or does *most* of the time), then for certain it's not the network specifically, but the way data is being delivered to the network via Ping Plotter.

The first sample with Ping Plotter has significantly more bandwidth usage than subsequent ones.

First off, the first sample *always* sends out 35 packets. Ping Plotter has no idea how long the actual route is - and it wants to return data as fast as possible, so it sends out 35 packets - each separated by a small time period (as specified in "Advanced Options" / Packet Option tab / Time interval between hop traces. This defaults to 25ms - which means with a 56 byte packet, you're looking at a bit over 2 K/s of bandwidth used. If you have more than a 56 byte packet specified, this is higher. Once Ping Plotter knows the route length (ie: sample 2 and beyond), it only sends out as many packets as is necessary to make the final destination. There is some chance that this will impact your bandwidth (I'm leaving out a TON of things here - in ideal situations, this actually wouldn't impact anything - but it's hard to know under non-ideal sitations).

Second, as individual results come back on the first sample, the routers that have responded also need to have their names looked up. This happens immediately as each hop responds back. This means that there is additional bandwidth being used at this point - as Ping Plotter talks to the DNS server(s). This handshaking doesn't take a lot of time, but it can overlap and has a chance to impact the first sample set's times.

If you want to see if this is impacting you at all, there are several ways to set Ping Plotter. First off, to disable the impact of the reverse DNS lookups, there's an option (on the same page of options as we discussed earlier) to disable threaded (concurrent) DNS lookups. Reset your trace and see if the behavior is any different.

Another way to minimize the impact of Ping Plotter's network usage is to change the time interval between hop traces. If you've got it set to 25, try changing it to 75 or 100. This will slow the rate at which Ping Plotter uses network resources.

If you're still seeing the same behavior when you've throttled down Ping Plotter's network usage, then it could possibly be a networking issue. If this is the case, I'd expect to see this happen only after a period of time when you hadn't contacted the final destination. Shutting down Ping Plotter and restarting it won't affect any ARP lookups on the network - so if it's reproducible within a matter of a few minutes, I'd look more at Ping Plotter's usage of network resources than I would at network itself.

Note that the issues talked about here *mostly* impact people on dial-up modems - or slow connections.

Let us know if this makes sense - and if changing any of the suggested settings changes the results you're seeing.

- Pete

Thanks for the reply!

Well, I don't think the problem is with ping plotter at all... If I increase the trace interval from 5 seconds to 60 seconds, not only is the first ping between 300-600 msecs at every hop except the first, but each additional ping is also slow (with bad packet loss, as well). When I had it set to 5 secs, only the first ping was slow.

If I try the same thing with the "ping" command line program, I get these results...

D:\Documents and Settings\Victor.ANAI-2U6J0N9SMT>ping www.attbi.com

Pinging www.attbi.com [63.240.76.8] with 32 bytes of data:

Reply from 63.240.76.8: bytes=32 time=391ms TTL=51
Reply from 63.240.76.8: bytes=32 time=79ms TTL=51
Reply from 63.240.76.8: bytes=32 time=75ms TTL=51
Reply from 63.240.76.8: bytes=32 time=75ms TTL=51

Ping statistics for 63.240.76.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 75ms, Maximum = 391ms, Average = 155ms

[Okay, now I'm waiting only about 5 seconds and entering the command again].

D:\Documents and Settings\Victor.ANAI-2U6J0N9SMT>ping www.attbi.com

Pinging www.attbi.com [63.240.76.8] with 32 bytes of data:

Reply from 63.240.76.8: bytes=32 time=74ms TTL=51
Reply from 63.240.76.8: bytes=32 time=72ms TTL=51
Reply from 63.240.76.8: bytes=32 time=70ms TTL=51
Reply from 63.240.76.8: bytes=32 time=72ms TTL=51

Ping statistics for 63.240.76.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 70ms, Maximum = 74ms, Average = 72ms

[Notice that the above time has improved for the first ping. Now I'll wait a whole minute and retype the command].

D:\Documents and Settings\Victor.ANAI-2U6J0N9SMT>ping www.attbi.com

Pinging www.attbi.com [63.240.76.8] with 32 bytes of data:

Reply from 63.240.76.8: bytes=32 time=381ms TTL=51
Reply from 63.240.76.8: bytes=32 time=73ms TTL=51
Reply from 63.240.76.8: bytes=32 time=73ms TTL=51
Reply from 63.240.76.8: bytes=32 time=74ms TTL=51

Ping statistics for 63.240.76.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 73ms, Maximum = 381ms, Average = 150ms

Latency seems to return after longer delays between pings. Is this a network problem? My cable connection seems significantly slower here than when I lived in Kansas City and had Road Runner. Would you like to see the data from pingplotter? Thanks!!!

OK. Definitely not Ping Plotter...

The next step is determine which hop in the route this latency is *starting* at. To do this, set your "# of times to trace" to 5. Run the trace to your destination. Set your "samples to include" to "ALL", then Edit / Copy as Text. Replace back here with the collected data (feel free to XXX out any data in your route you feel comprimises your security - such as the IP address at hop 1, etc.). Here's an example when I trace to that destination myself...

Target Name: www.attbi.com
IP: 63.240.76.8
Date/Time: 6/16/2002 9:38:52 PM

1 1 ms 1 ms 1 ms 1 ms 1 ms [10.0.0.1]
2 51 ms 50 ms 50 ms 51 ms 52 ms [205.160.15.3]
3 61 ms 52 ms 52 ms 51 ms 52 ms [205.160.15.2]
4 80 ms 68 ms 69 ms 69 ms 69 ms sl-gw7-che-5-0-0-ts22.sprintlink.net [144.232.251.105]
5 73 ms 68 ms 70 ms 69 ms 70 ms sl-bb20-che-0-0.sprintlink.net [144.232.15.246]
6 106 ms 104 ms 108 ms 107 ms 103 ms sl-bb21-tac-9-0.sprintlink.net [144.232.18.10]
7 105 ms 109 ms 106 ms 105 ms 107 ms sl-bb21-sea-8-2.sprintlink.net [144.232.9.222]
8 105 ms 105 ms 102 ms 107 ms 111 ms sprint-gw.st6wa.ip.att.net [192.205.32.173]
9 105 ms 106 ms 104 ms 105 ms 104 ms gbr4-p40.st6wa.ip.att.net [12.123.44.134]
10 119 ms 118 ms 126 ms 118 ms 125 ms tbr2-p012702.cgcil.ip.att.net [12.122.11.209]
11 117 ms 117 ms 120 ms 119 ms 137 ms tbr1-p013902.cgcil.ip.att.net [12.122.11.205]
12 137 ms 136 ms 136 ms 135 ms 137 ms tbr1-p012402.n54ny.ip.att.net [12.122.11.213]
13 134 ms 136 ms 135 ms 135 ms 155 ms gbr2-p10.n54ny.ip.att.net [12.122.11.6]
14 137 ms 133 ms 135 ms 136 ms 135 ms gar1-p370.n54ny.ip.att.net [12.123.1.133]
15 137 ms 135 ms 136 ms 135 ms 135 ms mdf1-gsr12-2-pos2-0.nyc3.attens.net [12.122.255.162]
16 139 ms 138 ms 140 ms 144 ms 139 ms sccsbix11-1-4.attbi.com [63.240.64.34]
17 135 ms 135 ms 133 ms 134 ms 141 ms www.attbi.com [63.240.76.8]

Ping statistics for www.attbi.com
Packets: Sent = 5, Received = 5, Lost = 0 (0.0%)
Round Trip Times: Minimum = 133ms, Maximum = 141ms, Average = 135ms

You can probably summarize which hop it's starting at by just talking about it here - but having some data to look at is always good too...

If this slowness is happening close to you (ie: hop 1-3), then this is something to do with your ISP. Try playing around with different destinations to see if it's all destinations or just a few of them. Once you've (we've) determined where the likely source of the problem is, you can create a strategy on solving the problem (ie: who to contact).

Now, before we get too far, what kind of performance do you see regularily? Is this something that you notice when you're using your browser or playing online games? Tying the data you're seeing to some problem that's affecting you is an important part of getting something fixed. If these symptoms aren't causing you any other problems, then you're going to have a hard time convincing anyone that they should be helping at all.