BT network congestion. You're not alone.

In reply to a post by XRaySpeX:

What's the diff in circumstances between the 2 TRACERTs you posted (other than the IPs arrived at)?

Or are you saying these are 2 random TRACERTs taken about the same time?

The two tracerts in my first post were done at the same time to different IPs (Both belonging to bbc.co.uk).

Edited by chris6273 (Wed 03-Apr-13 05:28:58)

In reply to a post by chris6273:

I'll try a reverse tracert tonight.

Did you do one - if so, what did that show?

Nick

In reply to a post by chris6273:

The two tracerts in my first post were done at the same time to different IPs (Both belonging to bbc.co.uk).

If you mean you predetermined the IPs to trace, rather letting the DNS decide the IP from the domain name, then those 2 TRACERTs don't prove anything. The faster could well be the duty server at that time for BBC and the slower one just a standby server. Their only diff was their time to respond.

In reply to a post by XRaySpeX:

In reply to a post by chris6273:

The two tracerts in my first post were done at the same time to different IPs (Both belonging to bbc.co.uk).

If you mean you predetermined the IPs to trace, rather letting the DNS decide the IP from the domain name, then those 2 TRACERTs don't prove anything. The faster could well be the duty server at that time for BBC and the slower one just a standby server. Their only diff was their time to respond.

It is a mixture of both. For the first post I had to manually specify the faster (Lower latency) one however the slower, higher latency IP was resolved from bbc.co.uk.

Even if they don't prove anything the problem is definitely still there according to BT's own asset. Here is a BT Speedtest showing my speed and latency during the problematic evening which every BT Customer is advised to use instead of speedtest.net:

http://imageshack.us/a/img22/3250/speedtest293.png

Does that help narrow things down? It can't be anything to do with the BBC's servers if BTs' Test Server is giving a high latency reading.

I'll do a reverse tracert a bit later when the problem is at its usual worst.

Edited by chris6273 (Wed 03-Apr-13 20:00:27)

In reply to a post by Lethe:

In reply to a post by chris6273:

I'll try a reverse tracert tonight.

Did you do one - if so, what did that show?

Nick

Sorry, I totally forgot to do one last night.

Here is one I have just done:

1 [AS8468] gi3-4.telford-dc1.core.enta.net (78.33.39.217) 0.372 ms 0.359 ms 0.199 ms
2 [AS8468] te4-4.wolv-te.core.enta.net (87.127.236.18) 0.822 ms 0.826 ms 0.666 ms
3 [AS8468] te4-4.stoke.core.enta.net (87.127.236.190) 1.447 ms 1.447 ms 1.292 ms
4 [AS8468] te1-6.man.core.enta.net (87.127.236.193) 2.852 ms 2.854 ms 2.695 ms
5 [AS8468] te5-1.telehouse-north0.core.enta.net (87.127.236.109) 9.560 ms 9.564 ms 9.559 ms
6 [AS2856] 194.74.65.57 (194.74.65.57) 13.777 ms 10.510 ms 11.751 ms
7 [AS2856] core2-te0-3-0-7.ilford.ukcore.bt.net (109.159.254.158) 17.818 ms 17.060 ms 16.115 ms
8 [AS2856] acc1-10GigE-0-7-0-0.bm.21cn-ipp.bt.net (109.159.248.3) 15.331 ms 15.335 ms 15.333 ms
9 [AS2856] 109.159.248.113 (109.159.248.113) 15.954 ms
[AS2856] 109.159.248.103 (109.159.248.103) 15.490 ms
[AS2856] 109.159.248.101 (109.159.248.101) 15.178 ms
10 [AS2856] 31.55.164.106 (31.55.164.106) 15.807 ms 15.800 ms 15.644 ms
11 [AS2856] 31.55.164.72 (31.55.164.72) 15.799 ms 15.804 ms 15.643 ms
12 [AS2856] 217.41.216.233 (217.41.216.233) 132.372 ms 136.870 ms
[AS2856] 217.41.216.153 (217.41.216.153) 19.862 ms
13 * * *

Looks like the hop in bold is the one giving a high latency figure in a reverse tracert. Does this help?

Those high figures in the intermediate nodes mean very little. In every case the response from the next node is "normal" which suggest that the nodes you have highlighted are moving data on and not holding it up in both directions.

In reply to a post by chris6273:

I'm not getting concerned over something that's totally irrelevant.

With traceroute you need to consider what you're measuring and what that means. Generally, traceroute results are unreliable to use for end to end latency measurement because they are greatly dependant on the response times of the supervisor software in the routers.

Routers are generally optimised to transmit packets through them and can be relativity slow to process errors such as packets exceeding their hop count. traceroute works by sending packets with an increasing hop count and getting an error response back from each router in turn as the router discovers the packet it receives has exceeded its hop count. The time taken by the router to do this is not a good measure of latency of packets travelling through the router.

In your traceroute output

1 <1 ms <1 ms <1 ms edge1-r-0-0-1.evansnet.co.uk [10.5.14.254]
2 8 ms 8 ms 9 ms 217.32.141.2
3 9 ms 8 ms 8 ms 217.32.140.222
4 13 ms 13 ms 13 ms 217.41.216.154
5 153 ms 151 ms 154 ms 31.55.164.69
6 14 ms 13 ms 15 ms 31.55.164.107
7 14 ms 14 ms 13 ms acc1-10GigE-0-0-0-5.bm.21cn-ipp.bt.net [109.159.
248.74]
8 22 ms 23 ms 23 ms core1-te0-15-0-15.ealing.ukcore.bt.net [109.159.
248.40]
9 18 ms 18 ms 17 ms acc1-10GigE-0-5-0-4.l-far.21cn-ipp.bt.net [109.1
59.254.104]
10 158 ms 159 ms 168 ms 194.74.65.42
11 * * * Request timed out.
12 20 ms 20 ms 20 ms ae0.er01.cwwtf.bbc.co.uk [132.185.254.93]
13 21 ms 21 ms 21 ms 132.185.255.156
14 144 ms 149 ms 150 ms www-vip.cwwtf.bbc.co.uk [212.58.253.67]

Hop 5 took 153ms but hop 6 took only 14ms. Time cannot have gone backwards by 139ms between hop 5 and 6 so something else must be going on. Chances are the supervisor software in hop 5 was in no hurry to respond to the traceroute packet reachnig its maximum hop count.

You need to measure the end to end latency using ping and see how that varies.

In reply to a post by chris6273:

I'm not getting concerned over something that's totally irrelevant.

You are confused by the significance of TRACERT results. Its primary purpose is to show the route taken to the final target. Only the final timing is of interest. If you are only interested in the timing then PING is sufficient.