ADSL24 High Ping on Weekends

I hope this is the right section. This is specifically related to game servers in Counter-Strike: Source and Team Fortress 2.

This only happens during weekends, during peak daytime hours, i.e. 11am-11pm roughly. Where I usually have 20ms in Steam's server browser, almost every server increases by up to 100ms. Speedtests seem to be completely unaltered from times when this is affecting me to when it isn't. I get around 36Mb down and 1.5 up no matter what. It began last weekend or the one before that.

My server browser. It isn't too bad right now, but notice how the UK server highlighted is ~70ms whereas it is usually in the low 20s.

Here is a trace route to that UK server. It seems to get stopped at 4.68.110.113. Here is another tracert to a server in the Netherlands on which I usually have 30ms.

This is the view of net_graph in Team Fortress which tracks your ping and packets lost. Notice the 1000ms spikes and just how [censored] unstable it is. In the past it has been a horizontal line right at the bottom of the graph.

This is my exchange.

Thanks for any help you can give.

Edited by ltadsl (Sun 29-Apr-12 19:23:52)

Your traceroutes show your pings are perfectly low and stable until well after they leave your ISPs network. In fact, the problem appears to be in peering between tinet and level3, both 3rd-party transit providers.

I find it strange that your ISP needs to go through two different transit providers to reach a London IP when it already has a POP in London. By the looks of things, routing is broken, both on your ISPs network and off it, the latter only showing up as a result of the former

Hm, okay. Is this an issue I should be taking up with my ISP, do you think?

Yes, kind of.

While the problem doesn't seem to be on your ISPs network, they do appear to be directly traffic strangely. I can't really say more than that, since I don't know what "normal" routing looks like for your ISP

But even so the extra hop to get to the destination is not causing any latency issues or packet loss so should not be relevent.

Here's a traceroute from our office line:

Tracing route to www.creativehosting.nl [80.69.77.156]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms x.x.x.x
2 12 ms 12 ms 12 ms lns2.uan.the.uk.murphx.net [94.30.127.73]
3 11 ms 11 ms 11 ms er1.uan.the.uk.murphx.net [94.30.127.65]
4 11 ms 11 ms 11 ms ge2-6-1.crs2.core.the.uk.murphx.net [94.30.127.233]
5 29 ms 28 ms 28 ms 195.50.122.69
6 29 ms 29 ms 28 ms ae-52-52.csw2.London1.Level3.net [4.69.139.120]
7 35 ms 37 ms 37 ms ae-57-222.ebr2.London1.Level3.net [4.69.153.133]
8 38 ms 38 ms 40 ms ae-46-46.ebr2.Amsterdam1.Level3.net [4.69.143.73]
9 38 ms 40 ms 48 ms ae-58-223.csw2.Amsterdam1.Level3.net [4.69.153.210]
10 38 ms 38 ms 38 ms ae-2-52.edge3.Amsterdam1.Level3.net [4.69.139.169]
11 41 ms 44 ms 47 ms TRANSIP-BV.edge3.Amsterdam1.Level3.net [212.72.33.110]
12 47 ms 49 ms 51 ms www.creativehosting.nl [80.69.77.156]

Trace complete.

On the contrary, I would say 17ms to cross London and 36ms to reach Amsterdam is a latency problem. That latency should be <1ms and <10ms respectively.

Here's a traceroute from my home line in Scotland, which has 15ms of interleaving on it and an extra 400 miles to travel - i.e. a total disadvantage of 27ms. It's still reaching the destination faster than from London on your network:

1 <1 ms <1 ms <1 ms n1.lan [10.1.0.11]
2 20 ms 20 ms 20 ms gateway.bt [217.32.142.104]
3 20 ms 20 ms 20 ms route-1.dc0-h1.bt [217.32.142.158]
4 26 ms 26 ms 26 ms route-3.dc1-h2.bt [213.120.163.26]
5 28 ms 27 ms 27 ms 217.32.27.78
6 26 ms 26 ms 26 ms route-0.dc1-h4.bt [217.32.27.178]
7 26 ms 26 ms 32 ms route-1.mr-h5.bt [109.159.250.94]
8 41 ms 35 ms 35 ms core1-te0-4-0-0.ealing.ukcore.bt.net [109.159.250.1]
9 33 ms 33 ms 33 ms transit1-pos1-0-0.telehouse.ukcore.bt.net [62.6.201.82]
10 32 ms 32 ms 32 ms t2as1-tge1-4.uk-lon1.eu.bt.net [166.49.211.141]
11 32 ms 32 ms 32 ms t2a1-ge4-0-0.uk-lon1.eu.bt.net [166.49.135.17]
12 32 ms 33 ms 32 ms te0-3-0-6.ccr21.lon01.atlas.cogentco.com [130.117.14.49]
13 41 ms 41 ms 41 ms te0-2-0-4.ccr21.lon13.atlas.cogentco.com [154.54.57.114]
14 41 ms 41 ms 41 ms te0-1-0-0.ccr21.ams03.atlas.cogentco.com [130.117.1.37]
15 41 ms 51 ms 40 ms te3-1.ccr01.ams02.atlas.cogentco.com [154.54.60.126]
16 40 ms 40 ms 40 ms transip-bv.demarc.cogentco.com [149.6.128.66]
17 40 ms 41 ms 40 ms www.creativehosting.nl [80.69.77.156]

Trace complete.

Your traceroute should be reaching the server in 20ms, not 47-51.

Same here, that's very high for UK

Sky LLU test

Tracing route to creativehosting.nl [80.69.72.146]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.0.1
2 8 ms 8 ms 39 ms ************bb.sky.com [*.*.*.*]
3 11 ms 11 ms 10 ms ip-84-38-37-12.easynet.co.uk [84.38.37.12]
4 11 ms 10 ms 11 ms te0-6-0-2.er10.txlon.ov.easynet.net [89.200.134.
121]
5 10 ms 8 ms 10 ms bu4.gr10.bllon.uk.easynet.net [89.200.135.143]
6 15 ms 15 ms 14 ms te1-0-0.gr10.saams.nl.easynet.net [87.86.77.60]

7 15 ms 15 ms 15 ms amsix.router1.dcg.transip.net [195.69.144.244]
8 16 ms 15 ms 15 ms www.creativehosting.nl [80.69.72.146]

Trace complete

Here is mine on my BE retail connection Fastpath enabled From the north west , Another example of how bad Telefonica's routing is , when you compare it to that of what was Easynet,now sky,

I had gotten used to how good their routing /peering was when i was with Ukonline Be retail

From telefonica onwards the latency is too high , and why it gets routed via Germany then the Netherlands i don't know, seems a longer route

Edited by tommy45 (Mon 30-Apr-12 17:31:02)

Thanks for all the responses.

For reference, this is my tracert to the same NL server right now. It's only during weekends when I get silly lag and it becomes unplayable. If it were a steady it would be manageable but my ping jumps around all over the place. In Team Fortress especially some packets seem to get lost (as you can see on the Team Fortress net_graph I linked in the original post).

Edited by ltadsl (Mon 30-Apr-12 18:08:05)

Looking back at both of ltadsl's and Adsl24's traceroutes, the problems appear to be with Level3 transit. In both cases, problems start when the traffic has left your ISP and hit Level 3's network. For ltadsl, traffic goes through tinet first, but there are no problems until it reaches Level3.

The problem could be either the link between your ISP and Level3 or Level3's network itself. Possibly more likely the latter, because traffic not going direct from your ISP to level3 is also affected (although when I route my traffic via the same hops its not affected, but then it's not the weekend right now either so its not exactly conclusive).

The UK server is actually hosted on Level3's network, so going via Level3 is unavoidable. The Netherlands server isn't, so your ISP could conceivably re-route traffic over a different provider until the problem with Level3 is resolved.