Bottleneck as Seen Through the Eyes of tracert

Album Cover: Icky Thump

"I'm gettin' hard on myself, sittin' in my easy chair."
White Stripes / 300 M.P.H. Torrential Outpour Blues

Posted on February 01, 2008 1:41 AM in Computers
Warning: This blog entry was written two or more years ago. Therefore, it may contain broken links, out-dated or misleading content, or information that is just plain wrong. Please read on with caution.

For the past week or so, I've been experiencing really slow connection times to any of the websites on my main web server (i.e. the one on which this blog is hosted). I originally contacted my web host, thinking that the problem was stemming from something on their end. However, they assured me that my server is running very fast and were able to back up their claim via the output of traceroute.

This concerned me, because a problem on the server side would have been pretty simple to address. Now I'm stuck in a situation where it seems like Comcast, my ISP, is having problems connecting to my personal web server, yet not any of the other websites I go to (e.g. Google).

Tonight I decided to run traceroute from my computer to my web server in an attempt to see if I could identify any bottlenecks. I was successful:

tracert -d

Tracing route to [] over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms
2 * * * Request timed out.
3 8 ms * 9 ms
4 9 ms * 23 ms

If you'll notice, in the output, there's a very obvious timeout that happens just as the request leaves my machine. However, I have no clue as to why this is happening, whether it could be due to something I've done, or if Comcast is to blame. If the latter is true, I have no idea whether it's something that will right itself over time, or if it will remain the way it is now until I bring the issue to their attention.

Does anyone out there with traceroute experience have any ideas as to what might be going on, or advice on how I should try and alleviate the problem?


Ryan on February 01, 2008 at 1:11 PM:

I think that the timeout you are seeing is pretty benign. Traceroute uses what is essentially a trick in the ICMP protocol (used for pinging) to find hosts between you and some remote server. As I understand it, the trick is this: traceroute sends the ICMP packet with a time to live (TTL) of one. This causes it to die at the first hop. Many servers consider it common courtesy to send a packet back when a packet dies at their server due to TTL expiration.

However, these days, it is also a somewhat common practice not to send these packets back. Essentially, one of the routers along the way is simply letting the ICMP packets die silently. There is no requirement that they do otherwise. The fact that servers further out are responding means that the intermediate router is doing its job of routing packets to and from you.

It appears that the non-responsive router is, in fact, the Comcast cable modem -- or whatever is directly on the other side of the modem if the modem is acting as only a bridge.

Running a traceroute from here shows similar behavior:

Tracing route to []
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms
2 * * * Request timed out.
3 7 ms * 8 ms []
4 17 ms * 9 ms []
5 9 ms * 10 ms []
6 11 ms * * []
7 * * * Request timed out.
8 22 ms 19 ms 18 ms []

Trace complete.


Bernie Zimmermann on February 01, 2008 at 2:49 PM:

Thanks for the information, Ryan. If you have (or anyone else has) any thoughts on what else I can try to get to the bottom of why accessing my web server has gotten so much slower from home, I'm all ears. It sounds like traceroute isn't really telling me much.

At the moment, I'm accessing the server from work and it is as snappy as I'd expect it to be.


Name on February 03, 2008 at 12:57 PM:

You really should be using something like mtr (winmtr when using windows) to diagnose this kind of problems. You probably can set the "interval" option to something as low as 0.1 seconds and you should wait for at least a few hundred packets to be sent. Single routers with high loss can be neglected if the next hop has zero (or very low) packetloss, as explained by Ryan. Then you can see at which hop packetloss or high latency times start.

For optimum diagnostics the result should be combined with a trace from the webhost to your home ip, because the packets do not necessarily take the same way in the opposite direction. If you start seeing packetloss, in reality it could mean that the _answer_ packets suffer from packetloss, because they take a different (bad) route on their way back to you.


Catherine on November 10, 2011 at 11:08 AM:

Agréable multiplex aisément accessible présentant des drames de Hollywood


ncddrwgk on May 15, 2017 at 5:23 AM:

Post Comments

If you feel like commenting on the above item, use the form below. Your email address will be used for personal contact reasons only, and will not be shown on this website.


Email Address:



Check this box if you hate spam.