-5 seconds? No, more traceroute funkyness!

The reported time included the time taken for the reporting router to realise it needs to report a packet with a zero TTL and send a ICMP packet reporting this. Routers often do this as a low priority task and so can take a while.

If you want a better guide to the response time then you need to ping each of the routers in the route that traceroute reports. You'll still be at the mercy of the routers ability to respond to the ping as opposed to route packets through the router.

Also, there's the whole issue about the return path not necessary being the same as out outbound path! Your delay could be in a router that's used on the return path and is not reported by traceroute.

If you're able to do a traceroute from both ends of a link you may find the routes are different.

Blinding me with science there, though I do follow you.

The thing is, I'm trying to explain to the OP in simple terms that he has got it wrong about his whole opening post. I think what you are telling me amounts to confirmation of that. So I was debunking his assertation that hop 17 = 16ms and hop 18 = 19ms means that a packet takes 6ms to get from router 17 to router 18. He hasn't got that yet. By highlighting the drop between hops 12 and 13 I show that is nonsense.

He is worried about the route taken, when the highest ping is from his target. The route taken, and the intermediate pings, (unless of course there is a persistent slow one and nearly all following it are above it), is irrelevant. It's not as if it routes through telia then to NY and then back to London.

As for tracert demonstrating that he is on fast path, you will know more than me. Maybe a number of 6ms ones show that? Maybe not. I'm just trying to think logically about it.

What do you think of the hop 11? I've only seen 1ms at hop 1, when the machine triggering the tracert reaches its own router.

In reply to a post by RobertoS:

The thing is, I'm trying to explain to the OP in simple terms that he has got it wrong about his whole opening post. I think what you are telling me amounts to confirmation of that. So I was debunking his assertation that hop 17 = 16ms and hop 18 = 19ms means that a packet takes 6ms to get from router 17 to router 18. He hasn't got that yet. By highlighting the drop between hops 12 and 13 I show that is nonsense.

I haven't got it wrong - here's a traceroute from my home to BBC. On Be fastpath, I was able to ping bbc.co.uk at 5ms. With BT FTTC, also fastpath, it's around 20ms probably because I'm routed via sheffield. In any event, there's something funny going on.

1 <1 ms <1 ms <1 ms 192.168.1.254
2 6 ms 5 ms 5 ms 217.32.147.97
3 6 ms 5 ms 6 ms 217.32.147.126
4 11 ms 10 ms 11 ms 213.120.181.182
5 11 ms 10 ms 11 ms 217.41.169.199
6 11 ms 12 ms 11 ms 217.41.169.109
7 11 ms 16 ms 10 ms acc2-10GigE-9-3-0.sf.21cn-ipp.bt.net [109.159.251.223]
8 18 ms 23 ms 23 ms core2-te0-0-0-6.ealing.ukcore.bt.net [109.159.251.159]
9 19 ms 19 ms 19 ms peer2-xe9-1-0.telehouse.ukcore.bt.net [109.159.254.114]
10 21 ms 21 ms 21 ms 194.74.65.42
11 * * * Request timed out.
12 58 ms 17 ms 19 ms ae1.er01.rbsov.bbc.co.uk [132.185.254.46]
13 21 ms 20 ms 20 ms 132.185.255.60
14 18 ms 18 ms 18 ms 212.58.241.131

Also, there's no need to explain things to me in simple terms - as complicated as possible would be good, please!

The reason it's 1ms at hop 11 is because the traceroute is from a server in London which is well connected.

Edited by deleted (Wed 29-Aug-12 22:53:55)

You can't be sure you're on fastpath unless you can see the router stats.

My understanding of fastpath is that it's an ATM protocol and thus only applies to the VDSL and ADSL part of the link. Basically ATM assumes that the physical path is reliable and does not do any error checking and expects the higher level protocols (TCP & IP) to do the error checking.

While the tracerotue is intersting the times are tricky to interpret because they are a mix of next work delay AND the routers ability to report packets dropped due to TTL being zero.

The important figure is the end to end ping time. Ping times to intermediate points give a better indication of network delays than traceroute times.

VDSL2 is PTM not ATM but if you can see the router stats you can tell if your connection is fastpath or not.

Right - I can make sense of that.

The difference seems to be simply that you are into the BT Wholesale WBC system, and the only way you avoid that on FTTC is Sky or TalkTalk. Be LLU centres around London and it doesn't surprise me that you had lower latency there to your secret IP, or to the Beeb.

The routing through Sheffield, (if it is Sheffield), is irrelevant - note that in your opening post you get 11ms to Ilford. You get to "Sheffield" on 6ms, and from then on a few at 9ms. The last two hops are where the problem lies, and may be better another time.

bsdnaz has given the technical description of tracert. I can follow what he says, a (not very) complicated technical overview of how it works, which confirms what I've been saying to you at a non-technical level.

The problem is essentially - I have 5ms to my first (non-router) hop, but 18ms to the BBC, so for some reason it is taking 13ms to cross London. There is no universe in which it should take 13ms to cross London. Sheffield is only irrelevant if you don't want to try and figure out why this is happening!

Using traceroute as a diagnostic tool shows the hop ending with .sf.21cn-ipp.bt.net - which I believe to be in Sheffield. Googling for 21cn-ipp.bt.net comes up with others' traceroutes which include hops such as .bm.21cn-ipp.bt.net (Birmingham) and .l-far.21cn-ipp.bt.net (London-Faraday) which correlates well with this list: http://www.kitz.co.uk/adsl/21cn_nodes.htm. Reading both forward and reverse traceroutes suggests (not directly, but mostly) about 6-7ms between London and Sheffield, which is within the bounds of reality given the distance involved.

So the semi-obvious conclusion is that for some reason my traffic is sent up to Sheffield before coming back down to London, resulting in higher latency than should be expected.

I would like this to change, and ideally would like <10ms to London based servers.
I do not think this is an unreasonable expectation. Waving it away as the vagaries of the BT WBC network is not a very satisfying answer. If the reason I'm sent to Sheffield and back is BT retail specific then that''s good, because it means that I can switch to another ISP and not have this problem. If it's BT WBC specific (maybe my exchange or cabinet is configured like this?) then it's bad, because switching to a BT wholesale ISP won't do anything.

I do not have the option of switching to Sky as they require line rental to be with them and I've already paid for that up front. Hence - the thread!

Edited by deleted (Thu 30-Aug-12 09:37:20)

While some latency is lost in the WBC network, I think this is more to do with how BT Infinity and BT Retail operates its WBC network, rather than an overall WBC issue e.g.

1    <1 ms    <1 ms    <1 ms  home.gateway.home.gateway [192.168.0.1]
2    18 ms    18 ms    19 ms  telehouse-gw4-lo1.idnet.net [212.69.63.98]
3    18 ms    18 ms    19 ms  telehouse-gw6-gi4-400.idnet.net [212.69.63.246]

4    17 ms    18 ms    18 ms  telehouse-gw5-gi4-400.idnet.net [212.69.63.245]

5    19 ms    19 ms    18 ms  rt-lonap-b.thdo.bbc.co.uk [193.203.5.91]
6     *        *        *     Request timed out.
7    18 ms    19 ms    19 ms  ae1.er01.rbsov.bbc.co.uk [132.185.254.46]
8    19 ms    19 ms    19 ms  132.185.255.60
9    19 ms    19 ms    19 ms  212.58.241.131

In short it is probably not as great because BT Retail contract their network to BT Wholesale so it uses more network than other providers, and thus bounces around due to load balancing/redundancy.

If it helps diagnostics along with Andrews trace, this is on one of our FTTC lines in Essex.

Tracing route to bbc.co.uk [212.58.241.131]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 10.1.1.254
2 9 ms 8 ms 8 ms lns16.the.dsl.enta.net [188.39.0.22]
3 8 ms 8 ms 8 ms gi1-6.the.dist.dsl.enta.net [188.39.0.21]
4 8 ms 8 ms 8 ms te2-2.telehouse-east3.dsl.enta.net [78.33.141.81]
5 8 ms 8 ms 8 ms te5-2.telehouse-east.core.enta.net [62.249.192.121]
6 11 ms 8 ms 8 ms bbc-linx.pr01.thdow.bbc.co.uk [195.66.224.103]
7 * * * Request timed out.
8 9 ms 9 ms 9 ms ae1.er01.rbsov.bbc.co.uk [132.185.254.46]
9 9 ms 13 ms 11 ms 132.185.255.60
10 9 ms 8 ms 8 ms 212.58.241.131

Trace complete.

Edited by vivaciti (Thu 30-Aug-12 10:06:06)