Kitz Forum
Broadband Related => ADSL Issues => Topic started by: usermac on February 15, 2015, 10:34:02 PM
-
I am connected directly to to the exchange spitting distance, I play online games and found out that if you remove interleaved your ping will be reduced. So I did this and cool it worked my ping was 10-15ms max. But now it feels like I am back on interleaved again it is so frustrating,I tried to explain this on the bt community forums but the same guys come back and say yeah this is normal there every time. There is no telling them that something does not feel right with my connection.
Tracing route to 185.16.86.18 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms BThomehub.home [192.168.1.254]
2 9 ms 9 ms 8 ms 213.1.174.250
3 8 ms 8 ms 8 ms 213.1.175.145
4 17 ms 17 ms 16 ms 213.1.69.122
5 21 ms 20 ms 20 ms 217.41.169.219
6 22 ms 23 ms 22 ms 217.41.169.109
7 23 ms 50 ms 22 ms acc2-xe-7-2-0.sf.21cn-ipp.bt.net [109.159.251.23
3]
8 32 ms 31 ms 29 ms core2-te-0-13-0-10.ealing.ukcore.bt.net [109.159
.251.179]
9 28 ms 28 ms 28 ms peer3-te0-7-0-0.telehouse.ukcore.bt.net [62.172.
102.5]
10 29 ms 29 ms 29 ms xe-0-2-4.rt0.thn.bandwidth.co.uk [195.66.225.123
]
11 29 ms 30 ms 28 ms xe-1-1-2.rt0.cr.bandwidth.co.uk [5.226.136.42]
12 31 ms 33 ms 31 ms 10ge-xe-0-1-1.ldn.uk.fragnet.net [217.146.92.6]
13 30 ms 30 ms 30 ms 185.16.86.18
Trace complete.
C:\Users\Ian>
-
3. Firmware version: Software version 4.7.5.1.83.8.130.1.17 (Type A) Last updated 04/05/14
4. Board version: BT Hub 4A
5. ADSL uptime: 3 days, 12:05:04
6. Bandwidth: 448 / 8128
7. Data sent/received: 746.7 MB / 790.8 MB
8. Broadband username: bthomehub@btbroadband.com
9. BT FON: Yes
10. 2.4 GHz Wireless network/SSID: BTHub4-ZN23
11. 2.4 GHz Wireless connections: Enabled (802.11 b/g/n (Recommended)) 20 MHz, WPS disabled
12. 2.4 GHz Wireless security: WPA and WPA2
13. 2.4 GHz Wireless channel: 6
14. 5 GHz Wireless network/SSID: BTHub4-5GHZ
15. 5 GHz Wireless connections: Enabled (802.11 n 40 MHz (Recommended)) 20/40 MHz, WPS disabled
16. 5 GHz Wireless security: WPA2
17. 5 GHz Wireless channel: 36
18. Firewall: Default
19. MAC Address: cc:33:bb:ac:ae:ec
20. VPI/VCI: 0 / 38
21. Modulation: G.992.1 Annex A
22. Latency type: Fast
23. Software variant: -
24. Boot loader: -
DSL noise margin: 29.00 dB upstream, 10.60 dB downstream
-
If wired no not normal , BT retails peering /routing is the reason , only solution is to change isp if 30ms is spoiling your online gaming experience
-
This is on Ethernet connection speed 1.0Gbps. Lol I do not think I will change isp as much as I would like to some day's. It is just annoying that they take a percentage off your download to be on the fast path. And fast path feels the same as interleaved did. It definitely is not spoiling anything it is just the principle it used to be better that's all.
-
From the latency it sure looks like its interleaved. - 29ms across the core network is too high unless youre way up in the Scottish Isles.
Where abouts in the UK are you? This makes a difference to early stage latency as the further from London you are then the higher it will be.
Im up in North West Lancs and I can reach London in 12ms
Tracing route to 185.16.86.18 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 192.168.1.1
2 12 ms 13 ms 12 ms lo0.12.central12.pcl-bng02.plus.net [195.166.130.153]
3 12 ms 12 ms 12 ms irb.12.pcl-cr02.plus.net [84.93.249.114]
4 12 ms 12 ms 12 ms ae2.pcl-cr01.plus.net [195.166.129.6]
5 12 ms 13 ms 12 ms ae1.ptw-cr01.plus.net [195.166.129.0]
6 13 ms 13 ms 12 ms xe-0-2-4.rt0.thn.bandwidth.co.uk [195.66.225.123]
7 13 ms 13 ms 13 ms xe-1-1-2.rt0.cr.bandwidth.co.uk [5.226.136.42]
8 13 ms 13 ms 12 ms 10ge-xe-0-1-1.ldn.uk.fragnet.net [217.146.92.6]
9 12 ms 12 ms 12 ms 185.16.86.18
Trace complete.
In fact I can go all the way down to London, back up the BTcore and reach your [exchange] backhaul router in 15ms.
Tracing route to 213.1.175.250 over a maximum of 30 hops
1 1 ms <1 ms <1 ms 192.168.1.1
2 12 ms 12 ms 12 ms lo0.12.central12.pcl-bng02.plus.net [195.166.130.153]
3 12 ms 12 ms 12 ms irb.12.pcl-cr01.plus.net [84.93.249.113]
4 13 ms 12 ms 13 ms 195.99.126.96
5 13 ms 13 ms 13 ms core3-te-0-0-0-18.faraday.ukcore.bt.net [109.159.249.41]
6 19 ms 15 ms 15 ms host213-121-193-44.ukcore.bt.net [213.121.193.44]
7 15 ms 14 ms 14 ms core2-pos1-2.reading.ukcore.bt.net [62.6.201.206]
8 15 ms 14 ms 15 ms 62.6.198.40
9 15 ms 15 ms 15 ms 213.1.175.250
Trace complete.
I'm reverse traversing your core routing via your RAS in 3ms. The same portion trip is taking you one heck of a lot longer.
It is just annoying that they take a percentage off your download to be on the fast path.
Im afraid thats not true. Its interleaving that eats into a portion of your sync speed.
However I note from your sync speed that you are on adsl1 for which the max speed is 8128 and your router is reporting Fast path, so I guess it must be very poor routing and not interleaving. Even so I find it odd that I can still traverse the same part of the core network and your backhaul quicker than you can. Is it your router, or is anything else using your connection?
-
I am from Winchester Hampshire. I am using the Home hub 4 and I have nothing else using my network.
-
>> Winchester Hampshire.
So In theory your latency to london should be fairly low, although you wont be on the core network for long. Your latency time for hop 2&3 is possible as that depends upon the length of your exchange backhaul before it joins the core. You seem to be hopping around at the RAS a bit and then why it should take so long to get on the core Ive no idea. There shouldn't ever be issues on the core.
I'm afraid this one has me scratching my head. Do you have another router you can try, I seem to recall something years ago about one of the HH's causing latency issues. I've just had a quick search but couldnt find the one I was thinking of. I did come across a couple of posts that recommended turning off UPnP in the HH which may be worth a try to see if it makes any difference.
-
9. BT FON: Yes
:D
If you ignore that then there is a clear doubling of ping between hop 3 and 4 which gains another 10ms at hop 8.
Kinda looks like BT 'routing' like someone else suggested already?
-
Also I in the troubleshooting list on the hub I have a lot of In Block Remote admin constantly going on so many pages.
IN: BLOCK [16] Remote administration (TCP 61.234.146.22:5145->86.131.174.191:22 on ppp0)
13:51:20, 15 Feb. (529607.490000) NTP synchronization success!
13:38:11, 15 Feb. IN: BLOCK [16] Remote administration (ICMP type 8 code 0 198.20.99.130->86.131.174.191 on ppp0)
13:24:14, 15 Feb. IN: BLOCK [16] Remote administration (TCP 222.186.59.100:6000->86.131.174.191:22 on ppp0)
13:21:13, 15 Feb. IN: BLOCK [16] Remote administration (TCP 188.138.17.205:9107->86.131.174.191:8080 on ppp0)
13:15:40, 15 Feb. IN: BLOCK [16] Remote administration (TCP 184.105.247.228:54099->86.131.174.191:443 on ppp0)
12:49:24, 15 Feb. IN: BLOCK [16] Remote administration (TCP 118.165.134.33:12200->86.131.174.191:8080 on ppp0)
12:49:12, 15 Feb. IN: BLOCK [16] Remote administration (TCP 118.165.134.33:12200->86.131.174.191:443 on ppp0)
12:35:41, 15 Feb. IN: BLOCK [16] Remote administration (TCP 5.196.105.72:39934->86.131.174.191:80 on ppp0)
12:14:35, 15 Feb. IN: BLOCK [16] Remote administration (TCP 218.59.238.92:12200->86.131.174.191:8080 on ppp0)
11:56:12, 15 Feb. IN: BLOCK [16] Remote administration (TCP 122.228.207.190:54987->86.131.174.191:22 on ppp0)
10:48:48, 15 Feb. IN: BLOCK [16] Remote administration (TCP 198.20.69.74:17535->86.131.174.191:443 on ppp0)
10:45:12, 15 Feb. (518440.000000) CWMP: session completed successfully
10:45:09, 15 Feb. (518436.830000) CWMP: HTTP authentication success from https://pbthdm.bt.mo
10:45:01, 15 Feb. (518428.400000) CWMP: Server URL: https://pbthdm.bt.mo; Connecting as user: ACS username
10:45:01, 15 Feb. (518428.400000) CWMP: Session start now. Event code(s): '2 PERIODIC,4 VALUE CHANGE'
10:45:00, 15 Feb. (518428.010000) CWMP: Initializing transaction for event code 2 PERIODIC
10:31:23, 15 Feb. IN: BLOCK [16] Remote administration (TCP 218.77.79.43:55428->86.131.174.191:22 on ppp0)
09:12:32, 15 Feb. (512879.840000) Admin login successful by 192.168.1.66 on HTTP
09:11:45, 15 Feb. BLOCKED 1 more packets (because of Spoofing protection)
09:11:45, 15 Feb. (512832.300000) Lease for IP 192.168.1.66 renewed by host Usermac (MAC c8:60:00:c9:68:16). Lease duration: 1440 min
09:11:45, 15 Feb. (512832.300000) Device connected: Hostname: Usermac IP: 192.168.1.66 MAC: c8:60:00:c9:68:16 Lease time: 1440 min. Link rate: 1000.0 Mbps
09:11:44, 15 Feb. IN: BLOCK [12] Spoofing protection (IGMP 86.131.174.191->224.0.0.22 on ppp0)
09:11:44, 15 Feb. BLOCKED 1 more packets (because of Spoofing protection)
09:11:44, 15 Feb. (512832.230000) Lease requested
09:11:42, 15 Feb. IN: BLOCK [12] Spoofing protection (IGMP 86.131.174.191->224.0.0.22 on ppp0)
09:11:42, 15 Feb. BLOCKED 1 more packets (because of Spoofing protection)
09:11:42, 15 Feb. (512830.120000) Wire Lan Port 4 up
09:11:41, 15 Feb. IN: BLOCK [12] Spoofing protection (IGMP 86.131.174.191->224.0.0.22 on ppp0)
09:11:39, 15 Feb. (512827.120000) Wire Lan Port 4 down
09:11:18, 15 Feb. (512806.120000) Wire Lan Port 4 up
09:01:12, 15 Feb. IN: BLOCK [16] Remote administration (TCP 201.150.36.119:59148->86.131.174.191:80 on ppp0)
08:02:28, 15 Feb. IN: BLOCK [16] Remote administration (TCP 192.151.147.210:44814->86.131.174.191:80 on ppp0)
07:09:05, 15 Feb. IN: BLOCK [16] Remote administration (UDP 184.105.139.67:36352->86.131.174.191:161 on ppp0)
06:57:33, 15 Feb. IN: BLOCK [16] Remote administration (TCP 45.56.114.75:53200->86.131.174.191:80 on ppp0)
06:51:12, 15 Feb. IN: BLOCK [16] Remote administration (TCP 80.82.64.116:58389->86.131.174.191:8080 on ppp0)
06:17:42, 15 Feb. IN: BLOCK [16] Remote administration (TCP 209.134.71.177:39063->86.131.174.191:80 on ppp0)
06:17:36, 15 Feb. IN: BLOCK [16] Remote administration (TCP 209.134.71.177:56923->86.131.174.191:8080 on ppp0)
06:12:02, 15 Feb. IN: BLOCK [16] Remote administration (TCP 61.240.144.64:60000->86.131.174.191:161 on ppp0)
05:35:57, 15 Feb. IN: BLOCK [16] Remote administration (UDP 192.210.198.194:39984->86.131.174.191:161 on ppp0)
04:47:03, 15 Feb. IN: BLOCK [16] Remote administration (TCP 103.41.124.60:9090->86.131.174.191:22 on ppp0)
04:34:37, 15 Feb. IN: BLOCK [16] Remote administration (ICMP type 8 code 0 211.140.101.66->86.131.174.191 on ppp0)
04:30:50, 15 Feb. IN: BLOCK [16] Remote administration (TCP 89.248.162.131:57364->86.131.174.191:443 on ppp0)
04:15:02, 15 Feb. IN: BLOCK [16] Remote administration (TCP 61.240.144.66:60000->86.131.174.191:80 on ppp0)
03:20:54, 15 Feb. IN: BLOCK [16] Remote administration (TCP 222.186.21.70:77->86.131.174.191:8080 on ppp0)
03:19:32, 15 Feb. IN: BLOCK [16] Remote administration (TCP 222.186.21.70:77->86.131.174.191:80 on ppp0)
03:15:45, 15 Feb. IN: BLOCK [16] Remote administration (TCP 218.200.104.40:55221->86.131.174.191:22 on ppp0)
03:13:32, 15 Feb. IN: BLOCK [16] Remote administration (TCP 1.169.90.145:12200->86.131.174.191:80 on ppp0)
02:19:02, 15 Feb. IN: BLOCK [16] Remote administration (TCP 61.160.224.128:58981->86.131.174.191:22 on ppp0)
02:02:03, 15 Feb. IN: BLOCK [16] Remote administration (TCP 45.56.114.75:34669->86.131.174.191:22 on ppp0)
01:42:02, 15 Feb. IN: BLOCK [16] Remote administration (UDP 93.180.5.26:33445->86.131.174.191:161 on ppp0)
01:30:40, 15 Feb. IN: BLOCK [16] Remote administration (TCP 141.212.122.28:45275->86.131.174.191:22 on ppp0)
01:02:20, 15 Feb. IN: BLOCK [16] Remote administration (TCP 80.82.64.116:40383->86.131.174.191:8080 on ppp0)
00:56:45, 15 Feb. IN: BLOCK [16] Remote administration (TCP 104.192.0.20:40667->86.131.174.191:80 on ppp0)
00:44:27, 15 Feb. IN: BLOCK [16] Remote administration (TCP 37.247.36.82:11436->86.131.174.191:443 on ppp0)
00:16:32, 15 Feb. BLOCKED 1 more packets (because of Spoofing protection)
00:16:30, 15 Feb. IN: BLOCK [12] Spoofing protection (IGMP 86.131.174.191->224.0.0.22 on ppp0)
00:13:45, 15 Feb. (480553.130000) Device disconnected: Hostname: Usermac IP: 192.168.1.66 MAC: c8:60:00:c9:68:16
00:13:45, 15 Feb. (480553.130000) Wire Lan Port 4 down
00:07:34, 15 Feb. (480181.410000) Admin login successful by 192.168.1.66 on HTTP
23:32:08, 14 Feb. IN: BLOCK [16] Remote administration (TCP 62.210.140.186:39257->86.131.174.191:22 on ppp0)
23:15:48, 14 Feb. IN: BLOCK [16] Remote administration (TCP 218.77.79.43:36134->86.131.174.191:8080 on ppp0)
23:01:31, 14 Feb. IN: BLOCK [16] Remote administration (TCP 1.163.69.130:12200->86.131.174.191:80 on ppp0)
22:45:48, 14 Feb. IN: BLOCK [16] Remote administration (UDP 134.147.203.115:28220->86.131.174.191:161 on ppp0)
22:45:35, 14 Feb. IN: BLOCK [16] Remote administration (TCP 188.138.17.205:50601->86.131.174.191:80 on ppp0)
22:35:44, 14 Feb. (474671.590000) Admin login successful by 192.168.1.66 on HTTP
22:08:02, 14 Feb. IN: BLOCK [16] Remote administration (TCP 61.160.224.128:58919->86.131.174.191:80 on ppp0)
22:02:36, 14 Feb. IN: BLOCK [16] Remote administration (TCP 218.77.79.43:33288->86.131.174.191:443 on ppp0)
21:43:15, 14 Feb. IN: BLOCK [16] Remote administration (TCP 198.58.75.132:1983->86.131.174.191:80 on ppp0)
21:07:04, 14 Feb. IN: BLOCK [16] Remote administration (TCP 182.254.132.201:55973->86.131.174.191:8080 on ppp0)
20:56:11, 14 Feb. IN: BLOCK [16] Remote administration (TCP 218.59.238.92:12200->86.131.174.191:8080 on ppp0)
20:53:17, 14 Feb. IN: BLOCK [16] Remote administration (TCP 183.136.214.95:6000->86.131.174.191:8080 on ppp0)
20:27:54, 14 Feb. IN: BLOCK [16] Remote administration (TCP 182.151.214.219:49332->86.131.174.191:8080 on ppp0)
20:27:53, 14 Feb. IN: BLOCK [16] Remote administration (TCP 182.151.214.219:51935->86.131.174.191:80 on ppp0)
20:21:47, 14 Feb. IN: BLOCK [16] Remote administration (TCP 218.77.79.43:46685->86.131.174.191:80 on ppp0)
20:11:56, 14 Feb. IN: BLOCK [16] Remote administration (TCP 61.160.224.128:56450->86.131.174.191:443 on ppp0)
20:07:10, 14 Feb. (465758.120000) Admin login successful by 192.168.1.66 on HTTP
18:57:28, 14 Feb. BLOCKED 1 more packets (because of Remote administration)
18:57:27, 14 Feb. IN: BLOCK [16] Remote administration (TCP 72.9.158.62:52109->86.131.174.191:22 on ppp0)
18:46:46, 14 Feb. IN: BLOCK [16] Remote administration (TCP 70.183.205.28:40571->86.131.174.191:8080 on ppp0)
18:10:00, 14 Feb. IN: BLOCK [16] Remote administration (TCP 115.231.218.147:9091->86.131.174.191:22 on ppp0)
18:05:37, 14 Feb. IN: BLOCK [16] Remote administration (TCP 198.84.222.208:55111->86.131.174.191:80 on ppp0)
18:05:32, 14 Feb. IN: BLOCK [16] Remote administration (TCP 198.84.222.208:35468->86.131.174.191:8080 on ppp0)
17:29:33, 14 Feb. IN: BLOCK [16] Remote administration (TCP 62.4.9.165:48212->86.131.174.191:22 on ppp0)
16:15:04, 14 Feb. IN: BLOCK [16] Remote administration (TCP 77.88.123.53:298->86.131.174.191:22 on ppp0)
16:13:56, 14 Feb. IN: BLOCK [16] Remote administration (TCP 122.228.207.190:34817->86.131.174.191:22 on ppp0)
16:02:56, 14 Feb. IN: BLOCK [16] Remote administration (TCP 80.82.64.116:46255->86.131.174.191:8080 on ppp0)
15:40:56, 14 Feb. IN: BLOCK [16] Remote administration (TCP 61.160.224.129:59039->86.131.174.191:8080 on ppp0)
15:36:40, 14 Feb. (449527.720000) Admin login successful by 192.168.1.66 on HTTP
15:15:07, 14 Feb. IN: BLOCK [16] Remote administration (TCP 122.228.207.77:42659->86.131.174.191:22 on ppp0)
14:35:28, 14 Feb. IN: BLOCK [16] Remote administration (TCP 46.165.220.215:43717->86.131.174.191:22 on ppp0)
14:25:54, 14 Feb. (445281.590000) Admin login successful by 192.168.1.66 on HTTP
14:06:48, 14 Feb. IN: BLOCK [16] Remote administration (TCP 204.151.197.45:17834->86.131.174.191:22 on ppp0)
13:52:40, 14 Feb. IN: BLOCK [16] Remote administration (TCP 45.56.96.33:58327->86.131.174.191:443 on ppp0)
13:52:18, 14 Feb. (443265.340000) Admin login successful by 192.168.1.66 on HTTP
13:52:13, 14 Feb. (443261.030000) New GUI session from IP 192.168.1.66
13:33:24, 14 Feb. IN: BLOCK [16] Remote administration (TCP 182.254.139.99:39359->86.131.174.191:8080 on ppp0)
13:32:45, 14 Feb. IN: BLOCK [16] Remote administration (TCP 61.240.144.65:60000->86.131.174.191:22 on ppp0)
13:31:02, 14 Feb. IN: BLOCK [16] Remote administration (TCP 211.90.1.201:57654->86.131.174.191:22 on ppp0)
13:14:51, 14 Feb. IN: BLOCK [16] Remote administration (TCP 115.231.218.23:9091->86.131.174.191:22 on ppp0)
-
Hi
I would not worry too much over those attempted logins as the service is disable on external connection.
Also, a quick glance over the offending IP addresses, most are from bots.
Lastly, you are not under heavy attack, I would say it is extremely light but I would advise you check which ports you have open and for which service, stopping those services if not needed is better.
Finally, if playing games online, most game servers take into account latency and try to equal it out for all players, unless your trying the lightswitch cheat.
I hope that helps a little
Many thanks
John
-
Something strange going on increased ping,Bots and poor peering. I think I have a bad Router. Its HH4 TYPE A. I think I am going to either arrange for a replacement or find a non bt one.
-
Hi
Personally I do not see your issue sorry.
I noted no tested to your destination ip, so I did a quick check as below.
We are on FTTC 80/20 and our results are similar to yours. I'm confident if other try same ping, they may well receive similar results, which there are many reasons why this may happen.
I could be entirely wrong with above, so I apologise in advance.
The bots hot everyone, if you have an external connection, you will be hit. Your degree of attack looks very minor to me, but then I'm comparing against our datacentre, but a quick look over our external attacks on our IP's here, still show your not on a high attack.
I hope that helps a little and as I said, I'm sorry if I'm wrong
Many thanks
John
--- Nice Trace to 185.16.86.18 ---
1) btbusinesshub.home (192.168.1.254) 3.624 ms, 24/24 ps, 0.0% loss
2) host81-139-192-1.in-addr.btopenworld.com (81.139.192.1) 18.948 ms, 24/24 ps, 0.0% loss [AS 2856] United Kingdom
3) 213.120.182.141 (213.120.182.141) 19.390 ms, 24/24 ps, 0.0% loss [AS 2856] United Kingdom
4) 213.120.161.82 (213.120.161.82) 19.750 ms, 24/24 ps, 0.0% loss [AS 2856] United Kingdom
5) 31.55.164.79 (31.55.164.79) 19.241 ms, 24/24 ps, 0.0% loss [AS 2856] United Kingdom
6) 31.55.164.107 (31.55.164.107) 18.674 ms, 24/24 ps, 0.0% loss [AS 2856] United Kingdom
7) acc1-10gige-0-3-0-7.bm.21cn-ipp.bt.net (109.159.248.118) 19.314 ms, 24/24 ps, 0.0% loss [AS 2856] United Kingdom
8) 109.159.248.180 (109.159.248.180) 23.880 ms, 24/24 ps, 0.0% loss [AS 2856] United Kingdom
9) peer5-te0-9-0-11.telehouse.ukcore.bt.net (109.159.252.47) 23.791 ms, 23/23 ps, 0.0% loss [AS 2856] United Kingdom
10) xe-0-2-4.rt0.thn.bandwidth.co.uk (195.66.225.123) 28.058 ms, 23/23 ps, 0.0% loss United Kingdom
11) xe-1-1-2.rt0.cr.bandwidth.co.uk (5.226.136.42) 25.993 ms, 23/23 ps, 0.0% loss [AS 25369] United Kingdom
12) 10ge-xe-0-1-1.ldn.uk.fragnet.net (217.146.92.6) 25.243 ms, 23/23 ps, 0.0% loss [AS 25369] United Kingdom
13) 185.16.86.18 (185.16.86.18) 24.301 ms, 23/23 ps, 0.0% loss [AS 25369] Sweden
-
If I am right FTTC does not allow you to be on fast path so the fact are pings are similar makes me think the interleaved is on but some how it is not reporting it.
-
Under FTTC whether you are on fast path or interleaved is controlled entirely by the DLM system. It may swtich you back and fro.
with FTTC neither you nor your ISP has any control over interleaving status and unlike plain ADSL it cannot be switched either on or off by the ISP.
-
Hi
Sorry I should have stated my tests were from my mobile over wifi.
Have you tried pinging directly from your home hub. I think you might find it is approx 5ms quicker, but would be interesting to know. The same ping from here is approx 19ms at home hub.
I also tried from our datacentre, to find out if there were any delays, and it was steady at 1ms.
Many thanks
John
-
ping 185.16.86.18 I am getting about 30-35.
-
If I am right FTTC does not allow you to be on fast path so the fact are pings are similar makes me think the interleaved is on but some how it is not reporting it.
To be blunt, no :)
He is interleaved (without a doubt). You are fastpath (without a doubt). The problem appears to be well beyond your house/router, based on what you've posted so far.
With that other stuff you posted, disable any UPNP/port forwarding, WAN management access and turn off the logging that reports it. Every IP on the planet is getting scanned for something, logging/reporting it is a waste of your resources :)
-
Although usermacs ping is high, I'd certainly assume that he is on FAST path,
1) That's what his router is reporting. FAST path is not capable of transmitting interleaved data.
Basically there are 2 different bearer channels down which data can be transmitted (FAST or Interleaved). The interleaved channel is capable of simulating fast but not vice versa.
2) He is syncing at a full 8128 on G.992.1 (g.DMT) . Usually interleaved adsl1 connections sync at 7616.
There are some exceptions to this ie account type is adslmax but the EU is attached to an adsl2+ capable MSAN.
3) Interleaving only occurs between the modem and DSLAM. The modem contains an interleaver/de interleaver, as does the DSLAM/MSAN.
----
FTTC always uses the Interleaved Path for data transmission. However, interleaved depth=1 is the equivalent of Fast Path as data is sent contigously without any chopping up and re-arranging of the data stream.
Im on FTTC with an Interleaved depth of 1
I'm also up in the NW, so you'd expect my latency to be slightly higher than someone living near to London. That said Im now on an MSE bRAS which is supposed to shave a 1or2ms from latency due to MSE bRAS's being nearer to local exchanges and can hop onto the core quicker whilst there are only a limited number of the old style bRAS's dotted around the UK.
Faster speed doesnt mean that you will get less latency. Latency is the measure of how long it takes a single packet to get from A -> B. The higher speeds dont decrease latency, you are just able to send more packets at once.
Over the years Ive been on 512k, 2Mb, 8Mb, 24Mb and 80Mb and its always taken me circa 14ms to get to London. Its only since my exchange moved to MSE bRAS last Oct that my latency to London reduced to 12/13ms.
----
My trace to 185.16.86.18 is in this post (http://forum.kitz.co.uk/index.php?topic=15045.msg280258#msg280258) and as you can see its 12ms.
Another thought occurred - what about BT Fon
-
I have opted out of BT FON but it is still showing it has been at least 48 hours.
3. Firmware version: Software version 4.7.5.1.83.8.130.1.17 (Type A) Last updated 04/05/14
9. BT FON: Yes
-
Just make sure you have entered the email address and password correctly and select opt out.
https://www.bt.com/wifi/secure/index.do?s_cid=con_FURL_btfon (https://www.bt.com/wifi/secure/index.do?s_cid=con_FURL_btfon)
and keep checking the router for BT FON: NO
-
I have a recollection that BT (Retail) routes are duplicated, but that some of the routing chosen are a bit strange - in particular, I've seen some people on the south coast (Portsmouth or Southampton, IIRC) who sometimes route via Sheffield, then back down to London.
The routing seems to be established when PPP authenticates, and stays fixed thereafter. A disconnection & re-connection (at PPP level) might induce a swap.
I could be *totally* wrong on this though - I don't recall enough to add any more details.
@kitz - when you did a ping back to the OP's exchange, I don't think you got the IP right - it looks like you mixed up the last 2 digits from 2 separate lines in the OP's traceroute.
I *think* the traceroute you needed was to 213.1.174.250, not 213.1.175.250
But, If I'm right at the top, then your packets may not end up routing in the same way.
-
The FON is now off, Still ping around 30 during the day and 40 in the evening. I seem to remember being routed through faraday exchange before when I used to have pings around 15. I guess there is nothing I can do. Unless I restart the hub but it had an SNR reset 7 days ago which makes me think I should leave it alone.
3. Firmware version: Software version 4.7.5.1.83.8.130.1.17 (Type A) Last updated 04/05/14
4. Board version: BT Hub 4A
5. ADSL uptime: 7 days, 03:43:08
6. Bandwidth: 448 / 8128
7. Data sent/received: 1.5 GB / 757.4 MB
8. Broadband username: bthomehub@btbroadband.com
9. BT FON: No
10. 2.4 GHz Wireless network/SSID: macs
11. 2.4 GHz Wireless connections: Enabled (802.11 b/g/n (Recommended)) 20 MHz, WPS disabled
12. 2.4 GHz Wireless security: WPA and WPA2
13. 2.4 GHz Wireless channel: 6
14. 5 GHz Wireless network/SSID: macs
15. 5 GHz Wireless connections: Enabled (802.11 n 40 MHz (Recommended)) 20/40 MHz, WPS disabled
16. 5 GHz Wireless security: WPA2
17. 5 GHz Wireless channel: 36
18. Firewall: Default
19. MAC Address: cc:33:bb:ac:ae:ec
20. VPI/VCI: 0 / 38
21. Modulation: G.992.1 Annex A
22. Latency type: Fast
-
I found an older trace.
Tracing route to 185.16.86.18 over a maximum of 30 hops
1 <1 ms <1 ms 1 ms BThomehub.home [192.168.1.254]
2 16 ms 15 ms 17 ms esr6.faraday2.broadband.bt.net [217.47.45.145]
3 17 ms 16 ms 17 ms 217.47.45.30
4 19 ms 19 ms 19 ms 213.1.69.86
5 17 ms 19 ms 19 ms 217.41.168.102
6 16 ms 18 ms 19 ms 217.41.168.149
7 17 ms 16 ms 17 ms 217.41.168.107
8 17 ms 19 ms 18 ms 109.159.249.110
9 19 ms 17 ms 17 ms core4-te-0-12-0-19.faraday.ukcore.bt.net [109.15
9.249.21]
10 18 ms 17 ms 18 ms peer5-te0-0-0-1.telehouse.ukcore.bt.net [194.72.
31.89]
11 18 ms 20 ms 22 ms xe-0-2-4.rt0.thn.bandwidth.co.uk [195.66.225.123
]
12 18 ms 19 ms 18 ms xe-1-1-2.rt0.cr.bandwidth.co.uk [5.226.136.42]
13 18 ms 19 ms 17 ms 10ge-xe-0-1-1.ldn.uk.fragnet.net [217.146.92.6]
14 17 ms 17 ms 17 ms 185.16.86.18
-
1 <1 ms <1 ms <1 ms BThomehub.home [192.168.1.254]
2 9 ms 9 ms 8 ms 213.1.174.250 [Device?]
3 8 ms 8 ms 8 ms 213.1.175.145 [Device?]
4 17 ms 17 ms 16 ms 213.1.69.122 [WHAT DEVICE IS THIS?! Double latency my ass! :) ]
If we had to have a wild stab in the dark as to what these devices are, what do we reckon? Is hop 4 going via a latency crippling tunnel of some sort?
Or, perhaps, is it going back on itself, somehow? The ping literally doubles...
-
I do not know what those devices are I only have my pc connected as far as I know? I as guessing they are something to do with BT.
-
Hi
If you ping faraday ip, you should have similar ping times matching your last post ping times. However, your no longer routed through it.
I would be more interested to know why your outgoing is so much higher then your incoming.
Are you running any services which account for this.
If not, you may want to look at what's using bandwidth on outgoing
Many thanks
John
-
I do not know what those devices are I only have my pc connected as far as I know? I as guessing they are something to do with BT.
Who knows. Is it worth posting another trace route? Are those pings consistent?
-
Hi boost
I would consider user mac would have similar ping timings unless the routing changes, but I don't think the routes at that level can be manipulated by user mac
User mac initial post was a gaming issues, ie game does not feel right
To qualify the gaming route matrix, use eMac would need the results for a ping from game server back to user mac ip, ideally a vector trace, but this would not include any game server balancing of latency between players in game. This is where the light switch cheat makes a difference.
I suspect it is the bandwidth usage for outgoing which is causing the issue, in that it may perhaps be packet loss, which trace route would not show fully.
I hope that helps and sorry if I'm wrong
Many thanks
John
-
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.
Tracing route to 185.16.86.18 over a maximum of 30 hops
1 1 ms <1 ms <1 ms BThomehub.home [192.168.1.254]
2 9 ms 10 ms 12 ms 213.1.174.250
3 8 ms 10 ms 7 ms 213.1.175.145
4 20 ms 19 ms 22 ms 213.1.69.122
5 23 ms 23 ms 24 ms 217.41.169.219
6 24 ms 24 ms 23 ms 217.41.169.109
7 23 ms 22 ms 22 ms acc2-xe-7-2-0.sf.21cn-ipp.bt.net [109.159.251.23
3]
8 30 ms 31 ms 31 ms core2-te-0-13-0-10.ealing.ukcore.bt.net [109.159
.251.179]
9 28 ms 29 ms 28 ms peer3-te0-7-0-0.telehouse.ukcore.bt.net [62.172.
102.5]
10 28 ms 30 ms 30 ms xe-0-2-4.rt0.thn.bandwidth.co.uk [195.66.225.123
]
11 28 ms 29 ms 30 ms xe-1-1-2.rt0.cr.bandwidth.co.uk [5.226.136.42]
12 33 ms 31 ms 31 ms 10ge-xe-0-1-1.ldn.uk.fragnet.net [217.146.92.6]
13 31 ms 31 ms 30 ms 185.16.86.18
Trace complete.
Tracing route to 185.16.86.18 over a maximum of 30 hops
1 <1 ms <1 ms 1 ms BThomehub.home [192.168.1.254]
2 9 ms 10 ms 12 ms 213.1.174.250
3 9 ms 12 ms 9 ms 213.1.175.145
4 21 ms 22 ms 20 ms 213.1.69.122
5 20 ms 21 ms 21 ms 217.41.169.219
6 21 ms 21 ms 21 ms 217.41.169.109
7 22 ms 22 ms 21 ms acc2-xe-7-2-0.sf.21cn-ipp.bt.net [109.159.251.23
3]
8 31 ms 31 ms 30 ms core2-te-0-13-0-10.ealing.ukcore.bt.net [109.159
.251.179]
9 28 ms 26 ms 28 ms peer3-te0-7-0-0.telehouse.ukcore.bt.net [62.172.
102.5]
10 27 ms 27 ms 27 ms xe-0-2-4.rt0.thn.bandwidth.co.uk [195.66.225.123
]
11 31 ms 29 ms 29 ms xe-1-1-2.rt0.cr.bandwidth.co.uk [5.226.136.42]
12 31 ms 34 ms 32 ms 10ge-xe-0-1-1.ldn.uk.fragnet.net [217.146.92.6]
13 30 ms 31 ms 30 ms 185.16.86.18
Trace complete.
-
Did this sort itself out by any chance or still ongoing?
-
Seems OK during the day but in the evening I get ping spikes and packet loss when playing on Battlefield 4 server I can only think it is due to how I am being routed.
Tracing route to 185.16.86.28 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms BThomehub.home [192.168.1.254]
2 10 ms 8 ms 9 ms 213.1.174.250
3 9 ms 9 ms 8 ms 213.1.175.161
4 19 ms 19 ms 18 ms 213.1.69.122
5 16 ms 16 ms 16 ms 217.41.169.87
6 16 ms 16 ms 16 ms 213.120.179.83
7 16 ms 15 ms 15 ms acc2-xe-4-2-0.sf.21cn-ipp.bt.net [109.159.251.22
9]
8 29 ms 22 ms 24 ms core1-te0-13-0-2.ilford.ukcore.bt.net [109.159.2
51.137]
9 27 ms 27 ms 29 ms peer3-te0-1-0-4.telehouse.ukcore.bt.net [109.159
.254.245]
10 20 ms 21 ms 20 ms xe-0-2-4.rt0.thn.bandwidth.co.uk [195.66.225.123
]
11 25 ms 24 ms 26 ms xe-1-1-2.rt0.cr.bandwidth.co.uk [5.226.136.42]
12 25 ms 26 ms 26 ms 10ge-xe-0-1-1.ldn.uk.fragnet.net [217.146.92.6]
13 22 ms 22 ms 21 ms 185.16.86.28
Trace complete.
-
Evening tracert winmtr
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| BThomehub.home - 0 | 4999 | 4999 | 0 | 0 | 15 | 0 |
| 213.1.174.250 - 1 | 4816 | 4769 | 8 | 21 | 258 | 10 |
| 213.1.175.161 - 2 | 4745 | 4680 | 8 | 21 | 297 | 152 |
| 213.1.69.122 - 3 | 4550 | 4436 | 20 | 35 | 307 | 78 |
| 217.41.169.87 - 4 | 4374 | 4216 | 17 | 31 | 303 | 75 |
| 213.120.179.83 - 4 | 4413 | 4265 | 18 | 33 | 307 | 22 |
| acc2-xe-4-2-0.sf.21cn-ipp.bt.net - 4 | 4381 | 4226 | 17 | 34 | 311 | 24 |
| core1-te0-13-0-2.ilford.ukcore.bt.net - 4 | 4458 | 4321 | 23 | 40 | 317 | 77 |
| peer3-te0-1-0-4.telehouse.ukcore.bt.net - 3 | 4518 | 4396 | 29 | 43 | 345 | 88 |
| xe-0-2-4.rt0.thn.bandwidth.co.uk - 4 | 4362 | 4201 | 23 | 39 | 313 | 26 |
| xe-1-1-2.rt0.cr.bandwidth.co.uk - 4 | 4462 | 4326 | 26 | 41 | 284 | 74 |
| 10ge-xe-0-1-1.ldn.uk.fragnet.net - 4 | 4373 | 4215 | 27 | 42 | 317 | 32 |
| 185.16.86.28 - 3 | 4534 | 4416 | 23 | 38 | 284 | 27 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider
-
Need some traceroutes from others on the same ISP, ideally.
-
As an aside, have you been playing with MTU/MSS anywhere on your LAN?
-
I did try tweaking the MTU using the guide on this site but did not work out to well so I put it back to default.
Could it be my noise margin causing higher latency?
3. Firmware version: Software version 4.7.5.1.83.8.204 (Type A) Last updated 08/03/15
4. Board version: BT Hub 5A
5. DSL uptime: 0 days, 18:38:41
6. Data rate: 448 / 8128
7. Maximum data rate: 1224 / 8128
8. Noise margin: 27.0 / 11.3
9. Line attenuation: 3.0 / 8.5
10. Signal attenuation: 3.0 / 7.9
11. Data sent/received: 4.3 GB / 30.2 MB
12. Broadband username: bthomehub@btbroadband.com
13. BT Wi-fi: No
14. 2.4 GHz Wireless network/SSID: BTHub5-5QTM
15. 2.4 GHz Wireless connections: Enabled (802.11 b/g/n (up to 144 Mb/s))
16. 2.4 GHz Wireless security: WPA2
17. 2.4 GHz Wireless channel: Automatic (Smart Wireless)
18. 5 GHz Wireless network/SSID: BTHub5-5QTM
19. 5 GHz Wireless connections: Enabled (802.11 a/n/ac (up to 1300 Mb/s))
20. 5 GHz Wireless security: WPA2
21. 5 GHz Wireless channel: Automatic (Smart Wireless)
22. Firewall: Default
23. MAC Address: 40:f2:01:0b:7a:66
24. VPI/VCI: 0 / 38
25. Modulation: G.992.1 Annex A
26. Latency type: Fast
27. Software variant: AA
28. Boot loader: 1.0.0
-
Hi usermac
What service are you running on outgoing data.
I ask because your sent data is shown as 4.3Gb but your received data is 30.2Mb.
I suspect it is this area which is causing you the issue
Many thanks
John
-
This is a red herring, I think.
Every trace he has posted has been latency consistent; indicative that he's aware his torrents are bw whorers and he stops them to provide the traces.
213.1.69 <--- Whatever this network/device is, it consistently shows higher latency. There are users on other forums providing traces that show the same thing. I can only assume this is a fault or a misconfiguration on this device. Still trying to work out what it might be...
-
Hi boost
Many thanks, I didn't know what service he was running.
John
-
Complete guess. If it turns out he's got a torrent box he forgot about I will look rather silly :D
I still think latency across his traces should be way more consistent than it is. I suppose we should rule out cosmetics too.
Can you ping and trace bbc.co.uk as well as this other server?
Can you also tcp ping both of them for comparison?
Cheers!
-
Hi boost
Many thanks, sorry I thought you knew the service.
Please see my results below, but was completed from mobile
Many thanks
John
TCP Ping
PING 185.16.86.18 (185.16.86.18)
36 bytes from 185.16.86.18 : icmp_seq=0 ttl=116 time=50 ms
36 bytes from 185.16.86.18 : icmp_seq=1 ttl=116 time=63 ms
36 bytes from 185.16.86.18 : icmp_seq=2 ttl=116 time=50 ms
36 bytes from 185.16.86.18 : icmp_seq=3 ttl=116 time=50 ms
36 bytes from 185.16.86.18 : icmp_seq=4 ttl=116 time=50 ms
36 bytes from 185.16.86.18 : icmp_seq=5 ttl=116 time=24 ms
36 bytes from 185.16.86.18 : icmp_seq=6 ttl=116 time=75 ms
36 bytes from 185.16.86.18 : icmp_seq=7 ttl=116 time=52 ms
36 bytes from 185.16.86.18 : icmp_seq=8 ttl=116 time=49 ms
36 bytes from 185.16.86.18 : icmp_seq=9 ttl=116 time=51 ms
36 bytes from 185.16.86.18 : icmp_seq=10 ttl=116 time=65 ms
36 bytes from 185.16.86.18 : icmp_seq=11 ttl=116 time=50 ms
36 bytes from 185.16.86.18 : icmp_seq=12 ttl=116 time=56 ms
36 bytes from 185.16.86.18 : icmp_seq=13 ttl=116 time=25 ms
36 bytes from 185.16.86.18 : icmp_seq=14 ttl=116 time=49 ms
36 bytes from 185.16.86.18 : icmp_seq=15 ttl=116 time=51 ms
--- 185.16.86.18 ping statistics ---
16 packets transmitted, 16 packets received, lost 0.0 %
PING bbc.co.uk (212.58.246.103)
36 bytes from 212.58.246.103 : icmp_seq=0 ttl=51 time=48 ms
36 bytes from 212.58.246.103 : icmp_seq=1 ttl=51 time=52 ms
36 bytes from 212.58.246.103 : icmp_seq=2 ttl=51 time=52 ms
36 bytes from 212.58.246.103 : icmp_seq=3 ttl=51 time=27 ms
36 bytes from 212.58.246.103 : icmp_seq=4 ttl=51 time=52 ms
36 bytes from 212.58.246.103 : icmp_seq=5 ttl=51 time=50 ms
--- bbc.co.uk ping statistics ---
6 packets transmitted, 6 packets received, lost 0.0 %
Trace results
--- Nice Trace to 185.16.86.18 ---
1) btbusinesshub.home (192.168.1.254) 4.701 ms, 18/18 ps, 0.0% loss
2) host81-148-128-1.in-addr.btopenworld.com (81.148.128.1) 23.560 ms, 18/18 ps, 0.0% loss [AS 2856] United Kingdom
3) 213.120.182.141 (213.120.182.141) 28.494 ms, 18/18 ps, 0.0% loss [AS 2856] United Kingdom
4) 213.120.161.82 (213.120.161.82) 19.968 ms, 18/18 ps, 0.0% loss [AS 2856] United Kingdom
5) 213.120.182.67 (213.120.182.67) 19.806 ms, 18/18 ps, 0.0% loss [AS 2856] United Kingdom
6) 31.55.164.107 (31.55.164.107) 22.163 ms, 18/18 ps, 0.0% loss [AS 2856] United Kingdom
7) 109.159.248.121 (109.159.248.121) 23.201 ms, 18/18 ps, 0.0% loss [AS 2856] United Kingdom
8) core1-te-0-13-0-4.ilford.ukcore.bt.net (109.159.248.136) 27.289 ms, 18/18 ps, 0.0% loss [AS 2856] United Kingdom
9) peer2-xe11-0-0.telehouse.ukcore.bt.net (109.159.254.130) 27.355 ms, 18/18 ps, 0.0% loss [AS 2856] United Kingdom
10) xe-0-2-4.rt0.thn.bandwidth.co.uk (195.66.225.123) 28.141 ms, 18/18 ps, 0.0% loss United Kingdom
11) xe-1-1-2.rt0.cr.bandwidth.co.uk (5.226.136.42) 25.945 ms, 18/18 ps, 0.0% loss [AS 25369] United Kingdom
12) 10ge-xe-0-1-1.ldn.uk.fragnet.net (217.146.92.6) 25.839 ms, 18/18 ps, 0.0% loss [AS 25369] United Kingdom
13) 185.16.86.18 (185.16.86.18) 24.329 ms, 18/18 ps, 0.0% loss [AS 25369] Sweden
--- Nice Trace to bbc.co.uk ---
1) btbusinesshub.home (192.168.1.254) 2.812 ms, 26/26 ps, 0.0% loss
2) host81-148-128-1.in-addr.btopenworld.com (81.148.128.1) 21.908 ms, 26/26 ps, 0.0% loss [AS 2856] United Kingdom
3) 213.120.182.141 (213.120.182.141) 23.252 ms, 26/26 ps, 0.0% loss [AS 2856] United Kingdom
4) 213.120.161.82 (213.120.161.82) 21.239 ms, 26/26 ps, 0.0% loss [AS 2856] United Kingdom
5) 213.120.182.67 (213.120.182.67) 20.856 ms, 26/26 ps, 0.0% loss [AS 2856] United Kingdom
6) 31.55.164.107 (31.55.164.107) 20.499 ms, 26/26 ps, 0.0% loss [AS 2856] United Kingdom
7) 109.159.248.95 (109.159.248.95) 23.100 ms, 26/26 ps, 0.0% loss [AS 2856] United Kingdom
8) core1-te0-3-0-15.ealing.ukcore.bt.net (109.159.248.28) 28.859 ms, 26/26 ps, 0.0% loss [AS 2856] United Kingdom
9) peer2-xe4-0-1.telehouse.ukcore.bt.net (109.159.252.39) 25.577 ms, 26/26 ps, 0.0% loss [AS 2856] United Kingdom
10) 194.74.65.42 (194.74.65.42) 25.120 ms, 26/26 ps, 0.0% loss [AS 2856] United Kingdom
11) * * *
12) ae0.er01.cwwtf.bbc.co.uk (132.185.254.93) 26.896 ms, 25/25 ps, 0.0% loss [AS 2818] United Kingdom
13) 132.185.255.165 (132.185.255.165) 27.771 ms, 25/25 ps, 0.0% loss [AS 2818] United Kingdom
14) fmt-vip133.cwwtf.bbc.co.uk (212.58.246.104) 26.997 ms, 25/25 ps, 0.0% loss [AS 2818] United Kingdom
-
Hi usermac
What service are you running on outgoing data.
I ask because your sent data is shown as 4.3Gb but your received data is 30.2Mb.
I suspect it is this area which is causing you the issue
Many thanks
John
I use One Drive to back up my files it might be that. I had a BT booster come round they requested a called a lift and shift. 5 days it should take so should be interesting to see the outcome after that. thanks for your interest
-
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.
C:\Users\Ian>tracert bbc.co.uk
Tracing route to bbc.co.uk [212.58.246.103]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms BThomehub.home [192.168.1.254]
2 9 ms 9 ms 8 ms 213.1.174.250
3 9 ms 9 ms 9 ms 213.1.175.161
4 24 ms 24 ms 24 ms 213.1.69.122
5 23 ms 23 ms 23 ms 217.41.169.247
6 21 ms 19 ms 19 ms 213.120.179.83
7 20 ms 21 ms 19 ms acc2-xe-5-2-2.sf.21cn-ipp.bt.net [109.159.251.24
7]
8 36 ms 34 ms 31 ms core2-te0-4-0-2.ealing.ukcore.bt.net [109.159.25
1.131]
9 30 ms 32 ms 31 ms peer2-xe4-1-1.telehouse.ukcore.bt.net [109.159.2
52.37]
10 28 ms 28 ms 29 ms 194.74.65.42
11 * * * Request timed out.
12 31 ms 33 ms 33 ms ae0.er01.cwwtf.bbc.co.uk [132.185.254.93]
13 32 ms 31 ms 31 ms 132.185.255.165
14 34 ms 33 ms 34 ms fmt-vip132.cwwtf.bbc.co.uk [212.58.246.103]
Trace complete.
1 <1 ms <1 ms <1 ms BThomehub.home [192.168.1.254]
2 9 ms 9 ms 9 ms 213.1.174.250
3 9 ms 9 ms 8 ms 213.1.175.161
4 23 ms 22 ms 23 ms 213.1.69.122
5 22 ms 23 ms 23 ms 217.41.169.247
6 20 ms 20 ms 20 ms 213.120.179.83
7 20 ms 22 ms 21 ms acc2-xe-5-2-2.sf.21cn-ipp.bt.net [109.159.251.24
7]
8 31 ms 36 ms 35 ms core2-te0-4-0-2.ealing.ukcore.bt.net [109.159.25
1.131]
9 30 ms 31 ms 42 ms peer2-xe4-1-1.telehouse.ukcore.bt.net [109.159.2
52.37]
10 28 ms 28 ms 29 ms 194.74.65.42
11 * * * Request timed out.
12 31 ms 32 ms 32 ms ae0.er01.cwwtf.bbc.co.uk [132.185.254.93]
13 31 ms 32 ms 32 ms 132.185.255.165
14 33 ms 33 ms 33 ms fmt-vip132.cwwtf.bbc.co.uk [212.58.246.103]
Trace complete.
-
I have a recollection that BT (Retail) routes are duplicated, but that some of the routing chosen are a bit strange - in particular, I've seen some people on the south coast (Portsmouth or Southampton, IIRC) who sometimes route via Sheffield, then back down to London.
The routing seems to be established when PPP authenticates, and stays fixed thereafter. A disconnection & re-connection (at PPP level) might induce a swap.
Any ideas how he fixes this WWWombat? :)
Presumably, he could be using a London BRAS instead of the borked Sheffield one?
-
I have a recollection that BT (Retail) routes are duplicated, but that some of the routing chosen are a bit strange - in particular, I've seen some people on the south coast (Portsmouth or Southampton, IIRC) who sometimes route via Sheffield, then back down to London.
The routing seems to be established when PPP authenticates, and stays fixed thereafter. A disconnection & re-connection (at PPP level) might induce a swap.
Any ideas how he fixes this WWWombat? :)
Presumably, he could be using a London BRAS instead of the borked Sheffield one?
If it is what I thought, then the routing would change at each new PPP session - at that point it would be pot luck whether it went via the midlands. Trying to disconnect at PPP level and re-connect (ie within the router) would perform this.
However, no-one came by with a similar recollection, so I wouldn't assume I'm close to being correct.
-
I have run a tracert to bbc.co.uk on this BTw line and the results
1 <1 ms <1 ms <1 ms BThomehub.home [192.168.1.254]
2 11 ms 12 ms 11 ms 217.32.142.106
3 11 ms 11 ms 11 ms 217.32.142.158
4 17 ms 17 ms 17 ms 212.140.206.18
5 17 ms 17 ms 17 ms 31.55.165.169
6 17 ms 17 ms 17 ms 31.55.165.107
7 20 ms 17 ms 17 ms 109.159.250.54
8 28 ms 27 ms 23 ms core1-te0-14-0-1.ealing.ukcore.bt.net [109.159.250.22]
9 27 ms 27 ms 26 ms peer2-xe3-0-0.telehouse.ukcore.bt.net [109.159.254.223]
10 24 ms 23 ms 24 ms 194.74.65.42
11 * * * Request timed out.
12 * * * Request timed out.
13 23 ms 24 ms 24 ms ae0.er01.telhc.bbc.co.uk [132.185.254.109]
14 27 ms 27 ms 27 ms 132.185.255.149
15 27 ms 27 ms 27 ms fmt-vip71.telhc.bbc.co.uk [212.58.244.20]
Trace complete.