Hi, it looks to me you are on WBC and having the same problems others are getting with too many connected and BT engineers not being able to cope with the faults.

It seems that the BT engineers have migrated more people to WBC than the equipment and the engineers can cope with and this is why some people are experiencing problems with speed and lost connections. Tech Support have been advised to flag up to their managers all customers who ring up and complain that they're having problems since migrating. These details are going to be passed along to goodness-knows who but they're going to look into the problems deeper.

http://forums.thinkbroadband.com/unhappiness/t/40030...


The stats from my connection on Orange LLU. I should be migrated to WBC in July.
Orange LLU use Noise Margin 10dB downstream, where BT WBC use 6dB, so I hope to get higher speeds on WBC.

Protocol: G.DMT2+ Annex A
Downstream Rate: 11717 kbps
Upstream Rate: 1108 kbps
Channel: Interleaved
Current Noise Margin: 10.2 dB (Downstream), 6.0 dB (Upstream)
Current Attenuation: 30.2 dB (Downstream), 14.9 dB (Upstream)
Current Output Power: 18.6 dBm (Downstream), 12.0 dBm (Upstream

Pinging google.com [209.85.143.99] with 32 bytes of data:

Reply from 209.85.143.99: bytes=32 time=45ms TTL=53
Reply from 209.85.143.99: bytes=32 time=43ms TTL=53
Reply from 209.85.143.99: bytes=32 time=46ms TTL=53
Reply from 209.85.143.99: bytes=32 time=43ms TTL=53

Ping statistics for 209.85.143.99:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 43ms, Maximum = 46ms, Average = 44ms

Well, I've been moved to WBC since 5 weeks and I've had no trouble with pings (in fact they have improved):

Pinging google.com [209.85.143.99] with 32 bytes of data:

Reply from 209.85.143.99: bytes=32 time=22ms TTL=52
Reply from 209.85.143.99: bytes=32 time=22ms TTL=52
Reply from 209.85.143.99: bytes=32 time=22ms TTL=52
Reply from 209.85.143.99: bytes=32 time=22ms TTL=52

Ping statistics for 209.85.143.99:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 22ms, Maximum = 22ms, Average = 22ms

However, my Sync is down from LLU by about 4 Meg. I have repeatedly reported this to TS but they have refused to do anything, saying, "that's all your line is capable of!". I have no impression that they are flagging my problem and are going to look into it deeper as you surmise.

Original poster needs to take things a step at a time

1. Data from the ADSL router, i.e. line sync, attenuation, noise margins - do these figures vary
2. Tracert rather than just pings
3. Use a target host that is not google.com e.g. pick something that is in London or another UK data centre

The issue from what we've seen could be congested transatlantic capacity for Orange based on what we can see, or it could be a badly performing telephone line. If the telephone line is good, then a change of provider to one who congests their BT rented capacity less may improve things.

there is something really odd about the ping times,

64 bytes from 209.85.143.99: icmp_seq=1728 ttl=50 time=5055 ms
64 bytes from 209.85.143.99: icmp_seq=1729 ttl=50 time=4055 ms
64 bytes from 209.85.143.99: icmp_seq=1730 ttl=50 time=3055 ms
64 bytes from 209.85.143.99: icmp_seq=1731 ttl=50 time=2054 ms
64 bytes from 209.85.143.99: icmp_seq=1732 ttl=50 time=1055 ms
64 bytes from 209.85.143.99: icmp_seq=1733 ttl=50 time=55 ms
64 bytes from 209.85.143.99: icmp_seq=1734 ttl=50 time=5060 ms
64 bytes from 209.85.143.99: icmp_seq=1735 ttl=50 time=4060 ms
64 bytes from 209.85.143.99: icmp_seq=1736 ttl=50 time=3061 ms
64 bytes from 209.85.143.99: icmp_seq=1737 ttl=50 time=2061 ms
64 bytes from 209.85.143.99: icmp_seq=1738 ttl=50 time=1061 ms
64 bytes from 209.85.143.99: icmp_seq=1739 ttl=50 time=61 ms

they are lowering 1000ms (+/-1) per sequence,
so is it 5 or 6 are batched up together, then all sent at the same time?

Batched - most ping utils send one ping and wait for a response not queue multiple pings.

Tracert would be more informative

Rather than using traceroute you would be better using MTR. Much better for diagnosing network issues. We're interested in packet loss not so much the route taken by the data.


HOST: ubuntu Loss% Snt Last Avg Best Wrst StDev
1. MyRouter.Home 0.0% 10 2.0 2.2 1.0 7.1 1.8
2. bm1.nselg-dhcp.isp.sky.com 0.0% 10 23.3 24.1 22.4 33.5 3.4
3. 10.245.133.17 0.0% 10 25.2 25.0 23.8 26.9 1.0
4. 89.200.131.193 0.0% 10 44.7 45.5 44.3 50.4 1.8
5. linx-gw1.rbsov.ncuk.net 0.0% 10 43.9 46.2 43.3 54.3 3.3
6. gi0-24-10-star1.core-rs2.thd 0.0% 10 49.3 48.3 45.8 52.4 1.9
7. thinkbroadband.com 0.0% 10 45.5 46.0 44.8 49.0 1.2