I connected to
http://centralops.net/co/ and used traceroute initially to connect to the cutin.edu.au site.
TRACEROUTETracing route to curtin.edu.au [134.7.179.53]...
| hop | rtt | rtt | rtt |
| ip address | domain name |
| 1 | 1 | 0 | 0 |
| 70.84.211.97 | 61.d3.5446.static.theplanet.com |
| 2 | 0 | 0 | 0 |
| 70.84.160.162 | vl2.dsr02.dllstx5.theplanet.com |
| 3 | 0 | 0 | 1 |
| 70.85.127.109 | po52.dsr02.dllstx3.theplanet.com |
| 4 | 0 | 0 | 0 |
| 70.87.253.21 | et3-1.ibr03.dllstx3.theplanet.com |
| 5 | 0 | 0 | 0 |
| 157.238.225.5 | xe-4-4.r03.dllstx09.us.bb.gin.ntt.net |
| 6 | 0 | 0 | 0 |
| 129.250.2.153 | ae-2.r20.dllstx09.us.bb.gin.ntt.net |
| 7 | 8 | 7 | 7 |
| 129.250.3.130 | as-0.r20.hstntx01.us.bb.gin.ntt.net |
| 8 | 5 | 5 | 5 |
| 129.250.3.25 | ae-0.r21.hstntx01.us.bb.gin.ntt.net |
| 9 | 50 | 49 | 49 |
| 129.250.3.121 | as-1.r21.lsanca03.us.bb.gin.ntt.net |
| 10 | 49 | 49 | 49 |
| 129.250.5.90 | xe-0-1-0.r03.lsanca03.us.bb.gin.ntt.net |
| 11 | 50 | 50 | 50 |
| 198.172.90.102 | p4-1-1-0.r03.lsanca03.us.ce.gin.ntt.net |
| 12 | 195 | 195 | 201 |
| 202.158.194.157 | so-3-3-1.bb1.b.syd.aarnet.net.au |
| 13 | 212 | 213 | 211 |
| 202.158.194.33 | so-2-0-0.bb1.a.mel.aarnet.net.au |
| 14 | 216 | 217 | 220 |
| 202.158.194.17 | so-2-0-0.bb1.a.adl.aarnet.net.au |
| 15 | 249 | 249 | 244 |
| 202.158.194.5 | so-0-1-0.bb1.a.per.aarnet.net.au |
| 16 | 249 | 244 | 247 |
| 202.158.198.178 | gigabitethernet0.er1.curtin.cpe.aarnet.net.au |
| 17 | 249 | 248 | 244 |
| 202.158.198.186 | gw1.er1.curtin.cpe.aarnet.net.au |
| 18 | 244 | 248 | 249 |
| 134.7.16.46 |
|
| 19 | 248 | 257 | 244 |
| 134.7.248.65 | te1-1.b309-sr.net.curtin.edu.au |
The results show that there were 19 hops before getting to this website. It took a little over two seconds in total for information to get from the tools website to Curtin and back again.
(correction: it took most of this time for Traceroute to convert all the IP addresses into URL names. Average time is average of last entry rtt (round trip times) which corresponds to ave reported below in Ping exercise.)PINGPinging curtin.edu.au [134.7.179.53] with 32 bytes of data...
Results
| count | ttl (hops) | rtt (ms) |
| from |
|
|
Statistics
| packets | sent | 5 |
|
| received | 5 | 100% |
| lost | 0 | 0% |
|
| times (ms) | min | 248 |
|
| avg | 249 |
|
| max | 252 |
|
The average time in milliseconds from the tools site to the curtin server was 249 ms.
How is this different to the total time traceroute reports???
Explained now, thanks to Glen who left his comments. I understand what Traceroute is doing a little better now.
I next downloaded the A-Tool bar from
http:// www.tucows.com/preview/323577 .
I pinged the webct site which took an average of 65ms. Compared to the time with the time taken to ping from the net tools siteof 149ms, this was greatly reduced. It is considerably less because the servers used would just have to transmit the message across Australia (Sydney to Perth) unlike before where the initial location was in the USA. The distance travelled and the number of servers it takes to transmit the information packets will dictate the time it takes - even though still very very fast.
1 comment:
Um, check the round trip times (RTT) in the traceroute output for the last hop: 0.248s, 0.257s, 0.244s. Compare this to the ping average time of 0.249s. Those figures are approximately the same.
You've been mislead by the time DNS takes to convert IP addresses to host names, which is what most of the elapsed 2s of the traceroute was spent doing. If you re-run the test the elapsed time could be very different (as the information is now in the DNS cache). The times you need to look at are the times reported by traceroute, not the elapsed time.
You should not use ping or traceroute to make more than vague assertions about network performance. Neither of these packets are dealt with by the forwarding plane of the router, as is the case for an average packet. We rate limit the number of both ping and traceroute packets to prevent denial of service attacks on our routers' control plane. We also put ping traffic into the Worst Effort QoS class to prevent ping flooding from succeeding against the usual Best Effort traffic.
Glen Turner, Network Engineer, AARNet
Post a Comment