topic Re: Moving an ONT, EE no longer provide the service? in Archived Posts

Moving an ONT, EE no longer provide the service?

TMaskell — Wed, 17 Nov 2021 17:33:50 GMT

I would like to relocate my ONT to a different part of the house. I've invested heavily in some new Unifi Equipment and want to store it in a rack in a completely different part of the house as to where my old all in one smart hub was. I phoned up at the beginning of summer and was told there was a minimum fee of £150 and to phone back when I needed the work done.

I phoned back today to be told that it is no longer a service that is provided by EE/Openreach and their advise was to find an electrician who could move it for me?

Now I'm happy to go down this route (if I can find anyone skilled/willing) but I was always under the impression everything up to and including the mastersocket/ONT was Open reaches property and should only be touched by them?

Has anyone had experience of this?

To clarify running a CAT7+ ethernet lead from the old location to the new rack would be completely impractical, moving the ONT is the most logical solution.

Tom

Re: Moving an ONT, EE no longer provide the service?

Chris_B — Wed, 17 Nov 2021 17:48:58 GMT

@TMaskell You don’t want an electrician you need a network engineer. Anyone can move a network point the only thing that can not be done is a new line from the telegraph pole to your home and for that you need open reach.

Re: Moving an ONT, EE no longer provide the service?

Mustrum — Wed, 17 Nov 2021 18:01:24 GMT

@TMaskell not quite sure what you mean - would the fibre need to be extended along the same path as the Cat cable, or are you looking for it to enter the building at a new point?

Either way, an electrician is unlikely to be able to splice fibre, and if someone other than Openreach were to try you would be liable for the charge to fix any issues.

Were it me I would try another CS rep, it may be the last one you spoke did not know how to arrange this, you may get one who does know if you try again.

Re: Moving an ONT, EE no longer provide the service?

TMaskell — Wed, 17 Nov 2021 18:35:11 GMT

Just spoken to another CS advisor. Not sure if the news is better or worse. Apparently the previous information was incorrect as suspected.... No one should touch BT's cabling... Shock!

They also said there is no way to request the move of an ONT/Master socket unless it's in an unsuitable location such as a bathroom. So apparently I'm stuck!

What's even more frustrating was that the CS advisor I spoke to at the start of summer said it was a straightforward job and had a standard charge of £150, which I was happy to pay?!

So who knows!

Re: Moving an ONT, EE no longer provide the service?

XRaySpeX — Wed, 17 Nov 2021 18:46:50 GMT

The ONT does not need to be on the same wall as the outside box. It can be moved (by OR) by extending its fibre connection but that's not a job for an electrician.

Re: Moving an ONT, EE no longer provide the service?

pip11 — Thu, 18 Nov 2021 10:33:40 GMT

If running an ethernet lead is impractical, how is running a fibre cable any better?

Re: Moving an ONT, EE no longer provide the service?

mikeliuk — Thu, 18 Nov 2021 14:16:42 GMT

Hi @TMaskell ,

If your latency requirements are not too demanding, have you considered a powerline adapter link between your server room and the ONT? This may add between 12 ms to 25 ms latency to the network path where the endpoints do not have WiFi functionality. For the powerline adapter I have with in-built WiFi AP, I find a higher latency of around 40 ms.

Below I show the ping first to a Devolo device in the server room, and then to a plain Devolo power line adapter with no WiFi functionality, and lastly to a Devolo powerline adapter with WiFi AP. The middle device has latency typically around 12 ms to 25 ms so the below is unusually good. The last two tests are between ring mains so if your hardware is on the same floor, your numbers may be better. You will see from the below, that there is a certain amount of jitter with power-saving mode enabled. It may be the same or a little better with power-saving disabled.

Depending on the network configuration of the ONT, you may need to isolate the PTP link from any other powerline network. In my case, I have a disconnected ONT (as I am with EE instead) downstairs which I believe I can just use a /30 or /31 to create a PTP link.

[x@x ~]$ for i in 192.168.4.{57,64,50}; do echo "= = = $i = = = "; ping -c 16 $i; done = = = 192.168.4.57 = = = PING 192.168.4.57 (192.168.4.57) 56(84) bytes of data. 64 bytes from 192.168.4.57: icmp_seq=1 ttl=58 time=1.02 ms 64 bytes from 192.168.4.57: icmp_seq=2 ttl=58 time=1.06 ms 64 bytes from 192.168.4.57: icmp_seq=3 ttl=58 time=1.05 ms 64 bytes from 192.168.4.57: icmp_seq=4 ttl=58 time=1.04 ms 64 bytes from 192.168.4.57: icmp_seq=5 ttl=58 time=1.06 ms 64 bytes from 192.168.4.57: icmp_seq=6 ttl=58 time=1.87 ms 64 bytes from 192.168.4.57: icmp_seq=7 ttl=58 time=1.05 ms 64 bytes from 192.168.4.57: icmp_seq=8 ttl=58 time=0.943 ms 64 bytes from 192.168.4.57: icmp_seq=9 ttl=58 time=0.991 ms 64 bytes from 192.168.4.57: icmp_seq=10 ttl=58 time=0.984 ms 64 bytes from 192.168.4.57: icmp_seq=11 ttl=58 time=1.09 ms 64 bytes from 192.168.4.57: icmp_seq=12 ttl=58 time=0.981 ms 64 bytes from 192.168.4.57: icmp_seq=13 ttl=58 time=1.01 ms 64 bytes from 192.168.4.57: icmp_seq=14 ttl=58 time=1.12 ms 64 bytes from 192.168.4.57: icmp_seq=15 ttl=58 time=0.982 ms 64 bytes from 192.168.4.57: icmp_seq=16 ttl=58 time=1.07 ms --- 192.168.4.57 ping statistics --- 16 packets transmitted, 16 received, 0% packet loss, time 32ms rtt min/avg/max/mdev = 0.943/1.081/1.868/0.210 ms = = = 192.168.4.64 = = = PING 192.168.4.64 (192.168.4.64) 56(84) bytes of data. 64 bytes from 192.168.4.64: icmp_seq=1 ttl=58 time=24.9 ms 64 bytes from 192.168.4.64: icmp_seq=2 ttl=58 time=24.4 ms 64 bytes from 192.168.4.64: icmp_seq=3 ttl=58 time=2.77 ms 64 bytes from 192.168.4.64: icmp_seq=4 ttl=58 time=2.11 ms 64 bytes from 192.168.4.64: icmp_seq=5 ttl=58 time=2.15 ms 64 bytes from 192.168.4.64: icmp_seq=6 ttl=58 time=2.03 ms 64 bytes from 192.168.4.64: icmp_seq=7 ttl=58 time=4.48 ms 64 bytes from 192.168.4.64: icmp_seq=8 ttl=58 time=3.97 ms 64 bytes from 192.168.4.64: icmp_seq=9 ttl=58 time=3.94 ms 64 bytes from 192.168.4.64: icmp_seq=10 ttl=58 time=3.44 ms 64 bytes from 192.168.4.64: icmp_seq=11 ttl=58 time=1.90 ms 64 bytes from 192.168.4.64: icmp_seq=12 ttl=58 time=1.94 ms 64 bytes from 192.168.4.64: icmp_seq=13 ttl=58 time=3.18 ms 64 bytes from 192.168.4.64: icmp_seq=14 ttl=58 time=3.76 ms 64 bytes from 192.168.4.64: icmp_seq=15 ttl=58 time=2.04 ms 64 bytes from 192.168.4.64: icmp_seq=16 ttl=58 time=2.07 ms --- 192.168.4.64 ping statistics --- 16 packets transmitted, 16 received, 0% packet loss, time 35ms rtt min/avg/max/mdev = 1.902/5.564/24.891/7.256 ms = = = 192.168.4.50 = = = PING 192.168.4.50 (192.168.4.50) 56(84) bytes of data. 64 bytes from 192.168.4.50: icmp_seq=1 ttl=62 time=6.95 ms 64 bytes from 192.168.4.50: icmp_seq=2 ttl=62 time=5.36 ms 64 bytes from 192.168.4.50: icmp_seq=3 ttl=62 time=4.36 ms 64 bytes from 192.168.4.50: icmp_seq=4 ttl=62 time=3.52 ms 64 bytes from 192.168.4.50: icmp_seq=5 ttl=62 time=3.20 ms 64 bytes from 192.168.4.50: icmp_seq=6 ttl=62 time=2.17 ms 64 bytes from 192.168.4.50: icmp_seq=7 ttl=62 time=40.0 ms 64 bytes from 192.168.4.50: icmp_seq=8 ttl=62 time=79.4 ms 64 bytes from 192.168.4.50: icmp_seq=9 ttl=62 time=40.5 ms 64 bytes from 192.168.4.50: icmp_seq=10 ttl=62 time=39.8 ms 64 bytes from 192.168.4.50: icmp_seq=11 ttl=62 time=38.9 ms 64 bytes from 192.168.4.50: icmp_seq=12 ttl=62 time=37.6 ms 64 bytes from 192.168.4.50: icmp_seq=13 ttl=62 time=35.3 ms 64 bytes from 192.168.4.50: icmp_seq=14 ttl=62 time=34.0 ms 64 bytes from 192.168.4.50: icmp_seq=15 ttl=62 time=33.8 ms 64 bytes from 192.168.4.50: icmp_seq=16 ttl=62 time=32.2 ms --- 192.168.4.50 ping statistics --- 16 packets transmitted, 16 received, 0% packet loss, time 34ms rtt min/avg/max/mdev = 2.170/27.312/79.378/20.643 ms

Re: Moving an ONT, EE no longer provide the service?

TMaskell — Fri, 19 Nov 2021 09:25:50 GMT

Running the Ethernet internally impractical from the current ONT to the new location. Externally/ via the loft is a very easy run for an open reach engineer.

Re: Moving an ONT, EE no longer provide the service?

TMaskell — Fri, 19 Nov 2021 09:28:05 GMT

Hi,

Unfortunately I've tried this option and it's not great. The living room and the cupboard are on separate rings. I know they say this shouldn't affect performance but it seems to... Drops from about 74mbps to 50mbps.

Re: Moving an ONT, EE no longer provide the service?

TMaskell — Fri, 19 Nov 2021 09:29:03 GMT

I think the outside box would need moving too as I would now like the service to enter the house into the first floor nor the ground floor.

Re: Moving an ONT, EE no longer provide the service?

mikeliuk — Fri, 19 Nov 2021 09:35:56 GMT

Hi @TMaskell ,

That's interesting to hear. Is that the dLAN models, Magic-1 or Magic-2 ?

I've managed to achieve 130 Mbps (Magic-2, separate rings) at the far end (away from the 4G LTE router) but, as you mention this, didn't test at a server near the router (will try to remember to do this next time around 4am when the network is not congested).

From the Magic-2 LAN triple (no WiFi AP) near the router, I see links/connections of

to WiFi AP: 1075 Mbps transmit, 1193 Mbps receive

to LAN "1-1": 727 Mbps transmit, 821 Mbps receive

as reported by the management page on the triple. Unfortunately I don't have a Linux device at the far end to run iperf but if I believe the link speeds, I should have enough headroom.

Perhaps Devolo Cockpit or the app (requires dLAN 500+ or better, I believe) can shed light on why 50 Mbps should be a bottleneck as I recall even the earliest Devolos were capable of 100 Mbps or 200 Mbps.

Re: Moving an ONT, EE no longer provide the service?

Mustrum — Fri, 19 Nov 2021 16:39:13 GMT

@mikeliuk whilst the use of Powerline adapters can be used in certain circumstances, this is not one. The connection between the ONT and WAN port on the router is 1Gbps. Even if mains sockets are in the same room, they will not provide the same connectivity as a Cat x cable.

I came across this article and test which shows speed being severely reduced as well as increased levels of jitter https://www.jiribrejcha.net/2020/08/throughput-speed-test-of-tp-link-and-devolo-magic-2-wi-fi-power-line-adapters-plc/

@TMaskell Unless you can find a friendly Openreach engineer it seems your options are limited. Maybe you will have to relook at the best way to get a Cat X cable between the ONT and the router?

Re: Moving an ONT, EE no longer provide the service?

mikeliuk — Fri, 19 Nov 2021 17:23:16 GMT

Hi @TMaskell ,

I would recommend that you consider the requirement for which you want to move the ONT. Perhaps you have moved your networking equipment and now wish to move the ONT to get better latency, less jitter, or better bandwidth than its current position allows. One key thing is to avoid trying to satisfy a requirement which you do not have, when you think more carefully about it.

If you have a latency-sensitive application, then I think moving the ONT or a suitable wired connection would make sense. An additional hop might add 12 ms.

If you are primarily concerned with bandwidth, moving the ONT is unlikely to help you because there should be no 50 Mbps bottleneck between the ONT and your server room even with fairly cheap consumer devices.

The way I have approached the issue is to go with EE 4G LTE in my server room attached to my firewall and near my routers and to use Devolo powerline adapters to reach my consumer devices. Due to the higher latency and high jitter of 4G LTE, this would be comparable to having a powerline data link between your ONT and server room.

I would recommend to try any option you have available first (i.e. for free), measure, and hold off from the temptation to speculate without data. So if you already own powerline adapters, run some simple jitter tests and monitor over a few days. To give you a concrete starting point, the below is a simple ping over a 4G LTE connection so any wired connection should improve on the jitter evident below. On the other hand, I would be happy to be proved wrong if you show that a powerline connection has worse jitter than my 4G LTE connection and I will take that onboard.

[x@x ~]$ ping -c 32 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=110 time=29.3 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=110 time=21.3 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=110 time=20.7 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=110 time=19.0 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=110 time=25.10 ms 64 bytes from 8.8.8.8: icmp_seq=6 ttl=110 time=22.1 ms 64 bytes from 8.8.8.8: icmp_seq=7 ttl=110 time=21.8 ms 64 bytes from 8.8.8.8: icmp_seq=8 ttl=110 time=40.7 ms 64 bytes from 8.8.8.8: icmp_seq=9 ttl=110 time=39.2 ms 64 bytes from 8.8.8.8: icmp_seq=10 ttl=110 time=39.8 ms 64 bytes from 8.8.8.8: icmp_seq=11 ttl=110 time=38.3 ms 64 bytes from 8.8.8.8: icmp_seq=12 ttl=110 time=36.7 ms 64 bytes from 8.8.8.8: icmp_seq=13 ttl=110 time=23.4 ms 64 bytes from 8.8.8.8: icmp_seq=14 ttl=110 time=34.6 ms 64 bytes from 8.8.8.8: icmp_seq=15 ttl=110 time=42.0 ms 64 bytes from 8.8.8.8: icmp_seq=16 ttl=110 time=30.1 ms 64 bytes from 8.8.8.8: icmp_seq=17 ttl=110 time=18.6 ms 64 bytes from 8.8.8.8: icmp_seq=18 ttl=110 time=22.8 ms 64 bytes from 8.8.8.8: icmp_seq=19 ttl=110 time=26.7 ms 64 bytes from 8.8.8.8: icmp_seq=20 ttl=110 time=18.8 ms 64 bytes from 8.8.8.8: icmp_seq=21 ttl=110 time=34.3 ms 64 bytes from 8.8.8.8: icmp_seq=22 ttl=110 time=19.7 ms 64 bytes from 8.8.8.8: icmp_seq=23 ttl=110 time=40.6 ms 64 bytes from 8.8.8.8: icmp_seq=24 ttl=110 time=28.7 ms 64 bytes from 8.8.8.8: icmp_seq=25 ttl=110 time=27.0 ms 64 bytes from 8.8.8.8: icmp_seq=26 ttl=110 time=34.4 ms 64 bytes from 8.8.8.8: icmp_seq=27 ttl=110 time=16.6 ms 64 bytes from 8.8.8.8: icmp_seq=28 ttl=110 time=32.7 ms 64 bytes from 8.8.8.8: icmp_seq=29 ttl=110 time=40.7 ms 64 bytes from 8.8.8.8: icmp_seq=30 ttl=110 time=40.7 ms 64 bytes from 8.8.8.8: icmp_seq=31 ttl=110 time=38.1 ms 64 bytes from 8.8.8.8: icmp_seq=32 ttl=110 time=28.5 ms --- 8.8.8.8 ping statistics --- 32 packets transmitted, 32 received, 0% packet loss, time 73ms rtt min/avg/max/mdev = 16.578/29.809/42.033/8.133 ms

After finishing typing the above, it occurred to me that I can show the jitter to my furthest Devolo powerline device. My first impression is that the jitter is higher but the latency is lower. Good luck!

[x@x ~]$ ping -c 32 192.168.4.64 PING 192.168.4.64 (192.168.4.64) 56(84) bytes of data. 64 bytes from 192.168.4.64: icmp_seq=1 ttl=58 time=8.35 ms 64 bytes from 192.168.4.64: icmp_seq=2 ttl=58 time=6.23 ms 64 bytes from 192.168.4.64: icmp_seq=3 ttl=58 time=3.61 ms 64 bytes from 192.168.4.64: icmp_seq=4 ttl=58 time=2.08 ms 64 bytes from 192.168.4.64: icmp_seq=5 ttl=58 time=2.83 ms 64 bytes from 192.168.4.64: icmp_seq=6 ttl=58 time=11.4 ms 64 bytes from 192.168.4.64: icmp_seq=7 ttl=58 time=8.81 ms 64 bytes from 192.168.4.64: icmp_seq=8 ttl=58 time=6.56 ms 64 bytes from 192.168.4.64: icmp_seq=9 ttl=58 time=2.77 ms 64 bytes from 192.168.4.64: icmp_seq=10 ttl=58 time=6.33 ms 64 bytes from 192.168.4.64: icmp_seq=11 ttl=58 time=4.34 ms 64 bytes from 192.168.4.64: icmp_seq=12 ttl=58 time=2.05 ms 64 bytes from 192.168.4.64: icmp_seq=13 ttl=58 time=3.15 ms 64 bytes from 192.168.4.64: icmp_seq=14 ttl=58 time=1.85 ms 64 bytes from 192.168.4.64: icmp_seq=15 ttl=58 time=7.42 ms 64 bytes from 192.168.4.64: icmp_seq=16 ttl=58 time=3.00 ms 64 bytes from 192.168.4.64: icmp_seq=17 ttl=58 time=3.35 ms 64 bytes from 192.168.4.64: icmp_seq=18 ttl=58 time=1.94 ms 64 bytes from 192.168.4.64: icmp_seq=19 ttl=58 time=4.44 ms 64 bytes from 192.168.4.64: icmp_seq=20 ttl=58 time=2.50 ms 64 bytes from 192.168.4.64: icmp_seq=21 ttl=58 time=2.10 ms 64 bytes from 192.168.4.64: icmp_seq=22 ttl=58 time=2.31 ms 64 bytes from 192.168.4.64: icmp_seq=23 ttl=58 time=4.38 ms 64 bytes from 192.168.4.64: icmp_seq=24 ttl=58 time=2.37 ms 64 bytes from 192.168.4.64: icmp_seq=25 ttl=58 time=2.40 ms 64 bytes from 192.168.4.64: icmp_seq=26 ttl=58 time=2.97 ms 64 bytes from 192.168.4.64: icmp_seq=27 ttl=58 time=6.31 ms 64 bytes from 192.168.4.64: icmp_seq=28 ttl=58 time=37.0 ms 64 bytes from 192.168.4.64: icmp_seq=29 ttl=58 time=34.9 ms 64 bytes from 192.168.4.64: icmp_seq=30 ttl=58 time=32.7 ms 64 bytes from 192.168.4.64: icmp_seq=31 ttl=58 time=29.8 ms 64 bytes from 192.168.4.64: icmp_seq=32 ttl=58 time=27.1 ms --- 192.168.4.64 ping statistics --- 32 packets transmitted, 32 received, 0% packet loss, time 67ms rtt min/avg/max/mdev = 1.850/8.669/37.007/10.515 ms

A quick mention that one of the references given above is a very good one and I've also pointed it out here: https://community.ee.co.uk/t5/Broadband-home-phone/Cry-for-help-Using-a-TP-Link-TD-W9970-with-the-EE-smart-hub/m-p/1069899

If one looks at the data in those tables, the jitter is stated as below 2 ms for all devices which may be survivable even for consumer usage. 😂

Re: Moving an ONT, EE no longer provide the service?

pip11 — Fri, 19 Nov 2021 17:39:42 GMT

@TMaskell wrote:
Running the Ethernet internally impractical from the current ONT to the new location. Externally/ via the loft is a very easy run for an open reach engineer.

Then use an external ethernet cable you can get then in various lengths up to 60mts from Ebay.