WeFibre (Telcom) varied bandwidth :: Fibre Broadband

General Discussion
>> Fibre Broadband

Pages in this thread: 1 | [2] | (show all)

Print Thread

Toonshorty
(member) Fri 21-Jun-24 22:12:34

Re: WeFibre (Telcom) varied bandwidth

[re: Toonshorty] [link to this post]

So just to update on this, I spoke with their support team who mentioned that others have reported similar behaviour. They got in touch this afternoon to say they have "made some changes on the OLT", my line disconnected some 30 minutes prior so that would line up.

Results look to be a bit mixed. YouFibre (London) and Hyperoptic (Manchester) both recorded results at around 250-300Mbps, but Zen (London) and Quickline (Leeds) were 75Mbps and 22Mbps respectively, although I got 200Mbps on a test an hour later. aql (Leeds) managed an unremarkable 4.37Mbps, but I was only able to get 300Mbps from this server on my Azure VM so that may well be somewhat server related. Exa Networks (Bradford) and IDNet (London) were 727 and 672 respectively, but these were both returning good results previously.

The only real result of note was Zen (London) dropping to 75Mbps as this was one of the servers that performed well previously. I posted the traceroute for this server a few days back:

Tracing route to speedtest02a.web.zen.net.uk [51.148.82.21]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.1.1
2 7 ms 7 ms 7 ms 100.64.0.1
3 7 ms 7 ms 7 ms 185.205.175.201.default.telcom.network [185.205.175.201]
4 8 ms 8 ms 8 ms cr1.ukf1.man--cr1.tcw1.man.telcom.network [185.108.168.146]
5 8 ms 7 ms 8 ms cr1.tcw1.man--cr1.man1.telcom.network [185.108.168.152]
6 8 ms 7 ms * 195.66.244.28
7 13 ms 13 ms 13 ms lag-2.br1.ixn-lon.zen.net.uk [51.148.73.195]
8 13 ms 13 ms 14 ms speedtest02a.web.zen.net.uk [51.148.82.21]

Having ran another traceroute again today, I now get the following:

Tracing route to speedtest02a.web.zen.net.uk [51.148.82.21]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.1.1
2 12 ms 11 ms 12 ms 100.64.0.1
3 12 ms 13 ms 12 ms 109.224.252.93
4 12 ms 12 ms 12 ms cr1.ldn1--cr1.ldn1.telcom.network [185.108.168.96]
5 13 ms 12 ms 12 ms cr1.ldn1--cr2.ldn1.telcom.network [185.108.168.84]
6 17 ms 17 ms 17 ms cr2.ldn1--cr1.man1.telcom.network [185.108.168.123]
7 17 ms * 18 ms 195.66.244.28
8 18 ms 18 ms 18 ms lag-2.br1.ixn-lon.zen.net.uk [51.148.73.195]
9 17 ms 17 ms 17 ms speedtest02a.web.zen.net.uk [51.148.82.21]

This looks to be consistent across connections, including Exa Networks which is still performing at 600Mbps+.

Tracing route to speed.exa.co.uk [82.219.4.110]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.1.1
2 12 ms 12 ms 11 ms 100.64.0.1
3 12 ms 14 ms 12 ms 109.224.252.93
4 12 ms 12 ms 12 ms cr1.ldn1--cr1.ldn1.telcom.network [185.108.168.96]
5 14 ms 12 ms 12 ms cr1.ldn1--cr2.ldn1.telcom.network [185.108.168.84]
6 17 ms 17 ms 22 ms cr2.ldn1--cr1.man1.telcom.network [185.108.168.123]
7 16 ms * 17 ms ixman-gw1.man-tcw.exa.net.uk [195.66.244.10]
8 18 ms 17 ms 18 ms brad-br-sr1.net.exa.net.uk [82.219.45.90]
9 18 ms 17 ms 17 ms 82.219.4.110

So on the whole that configuration change looks to have improved things slightly, although that could just be a coincidence.

XGS_Is_On
(experienced) Mon 24-Jun-24 11:11:10

Re: WeFibre (Telcom) varied bandwidth

[re: Toonshorty] [link to this post]

It looks as though you were previously going via a BRAS in Manchester and are now going via one in London. The extra latency is a round trip between London and Manchester by the looks of it, so you're going to London via Manchester then back to Manchester to get to Bradford.

If that BRAS in Manchester was overloaded this makes sense.

Can tell all this from that:

185.205.175.201.default.telcom.network [185.205.175.201]

is in Manchester

109.224.252.93

is in London, it's 5 ms extra to get from Manchester to London and back:

5 14 ms 12 ms 12 ms cr1.ldn1--cr2.ldn1.telcom.network [185.108.168.84]
6 17 ms 17 ms 22 ms cr2.ldn1--cr1.man1.telcom.network [185.108.168.123]

and your first hop, the 100.64.0.1 went up by exactly that amount when moved to London: you could quite easily be going on the same fibre you were before via whomever they are leasing capacity from between Manchester and London. The hops we can see seem similar once you've cleared the BRAS so can't see what's up, but if capacity/congestion would expect it to be worse at peak times and better off-peak.

Chrysalis
(legend) Mon 24-Jun-24 18:48:43

Re: WeFibre (Telcom) varied bandwidth

[re: daern] [link to this post]

In reply to a post by daern:
In reply to a post by Toonshorty:
I wanted to collate some more details on the issue before raising it as I know when I've questioned speeds in the past they just came back with the usual "it's a contended service" and tell you to update the router firmware.

Just be glad you are not dealing with Vodafone. A couple of years back they had a black hole on their network which was dropping traffic to certain Google IP addresses as a result of an error in the peering routing with them. It was easy to demonstrate, easy to reproduce and, unquestionably, easy to fix.

It took them *weeks* and the few of us that were technically competent were literally pulling our hair out trying to get through their technical support teams to actually speak to someone who knew which way up to place a keyboard on their desk. When every single call to every single tier of support elicited the same response - "Your wifi is not working? Have you rebooted your computer?" - it's hard to keep your cool on the phone. I've never known anything like it and I have a special place on my dartboard of shame reserved for the company with what I consider to be the worst technical support function on the planet.

You have some great data here and I hope you have better luck in getting it to the right person than I ever did with Vodafone!

(ps. Voda's problem ended up being some decommissioned peering kit within their network that had not been properly removed from their routing. Should have been a trivial fix, especially given the dozen or so IT professionals providing them with detailed information of what the problem was!)

Sadly that seems to be the typical approach to network fault finding.

The systems seem setup to try every possible avenue local to the subscriber first before considering their own network to be the problem, a big reason e.g why engineer call outs are done so often, as there is this eagerness to verify the local setup is ok and swapping CPE, I wonder how much money is wasted on all those wasted visits and repeat calls to tech support.

One thing I used to do many years ago was find the email address of the Networks team, they would often be possible to find by google the NOC for the ISP, and whenever I contacted them they would always thank me for informing them, and it was fixed very quickly, but now days I expect they not so easy to contact.

Pages in this thread: 1 | [2] | (show all)

Print Thread

Jump to