Is it true that traceroute directly reflects the speed or performance of the network? The reason I'm asking because I've tried tracerouting a site that has more hops, but sometime it shows up faster in the browser (the sites are text based, comparable in size, and cache/history was cleared). I don't know if this is a glitch or not. Could anyone explain? :)

Traceroute has part to do with the speed at which you get to the site, however not all of it.

What traceroute actually does, is contacts the different routers until it reaches its destination. Now if you think about it, your computer is sending a very small amount of information:
----------
Are you there?

Yes I'm here

---------

So what happens in some cases is that the traceroute may show 5 hops, but when you go there the site is very slow. This has to do with the server load or the amount of bandwidth available on both your connection and the server you are contacting.

Traceroutes aren't normally used to determine speed, it is used to locate problems in the path.

There is a full science behind traceroute which you can explore on your own. Have a look at : http://www.useforesite.com/tut_tracert.shtml
for more information.

However thats the basics of it.

Traceroute to some extent will tell you about the quality of a backbone/network. For example, I was tracerouting a hosting company that uses cogent. The company is located in Washington DC, about 400-500 miles away from me (Connecticut). But when I traceroute, I can see the packet went all over the US... it went to Chicago, LA, Dallas, before finally went Washington DC. So to reach the 500 miles destination, the package had to travel around 7000 miles. This is, for me, very bad and if I were somebody looking for hosting, I won't really chose this host.

But, there is another factor that come into play; how congested a network is. For example, a webserver having a capped bandwith at 1 mbps will be slower than a similar web server capable to burst to 100 mbps. So, if the webserver is already serving many accounts, that 1 mbps capped bandwith will likely be very cogested especially in peak hours. For this reason, I will not go with a company that has capped bandwith to their servers but rather choose to go with a company that offer fully burstable solution, at least to 10 mbps (if the servre is connected to 10 mbps switch) or if possible to 100 mbps.

Another reason why a network can be slow is because of packet loss. Have you tried to ping into the different networks and compare the packet losses? As a genreal rule of thumb, the bigger the packet losses, the slower the network.

Anyway ... I found this two programs, pingplotter (http://www.pingplotter.com) and visualroute (http://visualroute.visualware.com), to be very useful to learn about a network, at least to some extend.

cheers,
:beer:

as i understand it a tracert shows the route taken by data packets, the time taken between hops and in total and the number of hops. hops are basically representative of a stretch of fibre between routers? and routers add a slight overhead but there is no real correlation between speed and number of hops. i could ping from the top of the country to the bottom in 200 ms and one hop or i could ping locally in 15 ms and 5 hops, the two as i understand it dont have to be related.
as for the value of a tracert, it shows the networks involved in the transit, the latency (not capacity!) of the networks and allows you to assess lag.
site one may have more hops but that could be because the data is taking a different route which is faster but requires transversing a few networks but its still quicker. its not really a glitch just down to the latency rather then hops. could also be a throughput issue if the sites are large, but text shouldnt be.
if you paste the tracerts then maybe we could comment further but i dont think im too far wrong, altho im always glad to be proved wrong :)
best wishes

Thank you for the explanations guys :)

Grateful,