cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

This page is no longer active

close

   

For up-to-date information and comments, search the EE Community or start a new topic.

Moving an ONT, EE no longer provide the service?

TMaskell
Contributor
Contributor

Hi

 

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

13 REPLIES 13

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.

-- 
Contract SIM: Plan | Data | Usage | Check Status | Abroad | Chat | SMS | APN | PM
Wired: Check Speed | Test Socket | Faults | fast.com | speedtest.net
Mustrum
EE Community Star
EE Community Star

@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-... 

 

@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?

 

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...

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. 😂

-- 
Contract SIM: Plan | Data | Usage | Check Status | Abroad | Chat | SMS | APN | PM
Wired: Check Speed | Test Socket | Faults | fast.com | speedtest.net
pip11
Scholarly Contributor
Scholarly Contributor

@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.