Savva La Belle Pagehead Graphic

Our Route to You
( Your IP Address is: )

The table below shows the results of a TraceRoute run from our server to your PC (or firewall/proxy server).

TraceRoute Results

 1 (  0.004 ms  0.005 ms  0.005 ms
 2 (  0.005 ms  0.025 ms  0.006 ms
 3  500.POS3-0.GW5.ATL5.ALTER.NET (  9.956 ms  0.008 ms  0.006 ms
 4 (  0.006 ms  9.932 ms  0.006 ms
 5  192.ATM7-0.BR3.ATL5.ALTER.NET (  0.006 ms  0.006 ms  9.952 ms
 6 (  0.006 ms  0.006 ms  9.965 ms
 7 (  0.006 ms  0.006 ms  9.965 ms
 8 (  69.993 ms  69.998 ms  79.993 ms
 9 (  69.993 ms  79.997 ms  69.993 ms
10 (  79.993 ms  79.994 ms  69.992 ms
11 (  79.992 ms !X *  70.001 ms !X

Interpreting TraceRoute

TraceRoute sends out "datagrams" (ICMP packets) which carry instructions to send them back to us after they have been relayed a preset number of times (the "ttl" or "time to live" value). It measures the time (in milliseconds) required for the datagram to make the round trip. It keeps increasing the ttl value until it gets a reply from your PC or firewall/proxy server. In this way it can determine the number of "hops", or packet routers, between our server and you, the name (or IP Address) of each packet router, and the time required for a packet to reach each router and return. TraceRoute sends three datagrams to each router.

In the table above, the first entry is the gateway by which our packets enter our presence provider's network. The second entry is the gateway by which our packets leave our presence provider's network, headed for the Internet. The third entry is the gateway by which our packets enter our Internet backbone connection provider's network. The last entry is your PC or firewall/proxy server. You will have to use a little guesswork to identify the remaining lines (see below).

The format for each line is: Number of Hops, Name and/or IP Address of the computer returning the datagrams, and Time (in milliseconds) required for each of the three datagrams to return. If one or more of the datagrams was lost (never returned), this is indicated by an asterisk (*) at the beginning of the line for each lost datagram.

TraceRoute Example

The example below shows typical TraceRoute results from our server (in Atlanta, GA USA) to our Webmaster's home PC (in Fort Worth, TX USA). This routing required 12 "hops". Our Webmaster's ISP is, and the backbone our packets routed over belonged to

  1  router254 (  0.9 ms  0.834 ms  0.814 ms
  2 (  0.697 ms  0.615 ms  0.664 ms
  3  32.ATM0-0-0.GW3.ATL1.ALTER.NET (  2.05 ms  1.988 ms  2.145 ms
  4  106.ATM2-0.XR2.ATL1.ALTER.NET (  1.931 ms  1.971 ms  1.873 ms
  5  294.ATM2-0.TR2.ATL1.ALTER.NET (  2.207 ms  2.191 ms  2.313 ms
  6  109.ATM6-0.TR2.DFW4.ALTER.NET (  19.961 ms  20.041 ms  20.032 ms
  7  298.ATM7-0.XR2.DFW4.ALTER.NET (  20.058 ms  20.271 ms  20.194 ms
  8  194.ATM11-0-0.GW1.DFW1.ALTER.NET (  25.881 ms  20.548 ms  20.995 ms
  9 (  26.227 ms  31.826 ms  34.503 ms
 10 (  36.404 ms  36.955 ms  35.613 ms
 11 (  39.243 ms  34.541 ms  27.385 ms
 12 (  183.122 ms  169.562 ms  157.099 ms

With that information, we can make pretty reliable guesses that our packets left the Atlanta area through the packet router on line 5, and arrived in the Dallas - Fort Worth area through the packet router on line 6. They left's network through the gateway on line 9, and entered's network through the gateway on line 10. Finally, they were sent from the hub on line 11 over a 28.8 kbps telephone modem connection to our Webmaster's PC.

You can use the same sort of reasoning to figure out what is happenning as our pages are downloaded to you.


In some cases when traffic congestion is the problem, you may be able to improve your download times by logging out of your ISP and re-connecting. This may result in your connection being routed to us through a different, faster hub.

If you experience frequent slow or incomplete loading of our pages that does not seem to be explained by any of the above information, please notify <>. We'll do our best to find the cause, and fix it if we can.