Odd issue with new FTTP

I have recently joined EE, moved from BT G.Fast to EE 300/50 FTTP.

Using all the same personal equipment that previously connected to the BT service, to connect to the new … everyone in the house notices a brief ‘delay’ before web pages start to open.
I reconnected the G.fast, and everything operates fine as before…..

Speed tests to the FTTP are rock solid, 300+ down…

In every other way it seems , as I expect, from FTTP. But still the weird momentary delay persists.

Using the CP supplies ‘hub 7 ultra’

Any ideas anyone ? It is a ‘non event’ but is a tad irritating.

In reply to a post by Zarjaz:

I have recently joined EE, moved from BT G.Fast to EE 300/50 FTTP.

Using all the same personal equipment that previously connected to the BT service, to connect to the new … everyone in the house notices a brief ‘delay’ before web pages start to open.
I reconnected the G.fast, and everything operates fine as before…..

Speed tests to the FTTP are rock solid, 300+ down…

In every other way it seems , as I expect, from FTTP. But still the weird momentary delay persists.

Using the CP supplies ‘hub 7 ultra’

Any ideas anyone ? It is a ‘non event’ but is a tad irritating.

Could it be DNS causing the delay? try temporarily overriding the DNS locally on one of the affected devices with different DNS services like Cloudflare and see if its better then at least you know whats causing it.

Thanks for that …. if I’m honest, I’m unsure how I might do that on either iPad or iPhone …..

Happy to schooled though.

In reply to a post by Zarjaz:

Thanks for that …. if I’m honest, I’m unsure how I might do that on either iPad or iPhone …..

Happy to schooled though.

Sadly I've never used an iPad or iPhone so I'm no help, hopefully someone familiar with doing it on those types of device will step forward. I know some may google it and present the answer as their own but I don't want to do that to you.

Open Settings > Wi-Fi, tap the "i" info icon next to your network, select Configure DNS, choose Manual, and add your new DNS addresses. You must delete existing addresses and tap Save to apply changes. This changes settings only for the current network


The IP address of Google DNS is 8.8.8.8,

Many Many Moons ago when Think Broadband used to post monthly quality/speed articles for the main ISPs I have a vague memory of there being a note about EE BB having a problem just like you describe. Used to effect their latency ratings. Speed was ok but it felt like it took a slight pause from making a request to it being acted upon. Did not effect their mobile BB. Also think this was before EE became part of BT.

Also knew some one who was on Talk Talk and went to EE ADSL when they offered a deal because they used EE mobile. Service was so poor they quit and went back to TT. This was also before EE became part of BT.

If one of the TBB staff read this maybe they can remember/explain further.

Have you tried pinging bbc.co.uk on each conection and comparing the results?

Anthony

Thanks for that Micheal

Be mindful that you may be connecting via IPv4 or IPv6 on your EE connection so to fully test make sure you add temporary DNS for both types if the device supports it.

I normally use Quad9 - https://quad9.net/

Whether a DNS query is made over IPv4 or IPv6 does not affect whether you will connect to the target site over IPv4 or IPv6. That is, a DNS query made over IPv4 can return an IPv6 address, and vice versa.

Text
1 23 45 67 89	% dig +short @8.8.8.8 forums.thinkbroadband.com. aaaa forums.thinkbroadband.com.cdn.cloudflare.net.2606:4700:10::6814:e32 2606:4700:10::6814:f32  % dig +short @2001:4860:4860::8888 forums.thinkbroadband.com. aforums.thinkbroadband.com.cdn.cloudflare.net. 104.20.15.50104.20.14.50

For the OP's problem I think there are two main possibilities:

1. EE are pointing at two different DNS servers but the first is broken, so the client is timing out and retrying the DNS request to the second.
2. EE is configuring clients with both IPv4 and IPv6, but the IPv6 path is broken, so the client is trying IPv6 first and then falling back to IPv4 (a.k.a. "happy eyeballs"). There are many causes of "IPv6 path is broken", including things like path MTU discovery is broken, which can be caused via ICMP blocking by the router or the network.

For case 2: to determine whether the site is actually being reached via IPv4 or IPv6, you can use a browser plugin like IPvFoo for Chrome. If you connect to a site which you know implements IPv6, and the client is successful with IPv6, then it rules out this case. But if everything connects over IPv4, even to IPv6-supporting sites, then IPv6 is broken. Disabling IPv6 either in the router or on individual clients should make things run faster.

For case 1: firstly, see what DNS servers your clients are picking up via DHCP (e.g. Windows: "ipconfig /all").

If these DNS servers are the router's own IP address (e.g. DNS server IP matches gateway IP) then the router itself is doing DNS forwarding. You'd then have to look at the router settings to see what DNS servers the router is forwarding to.

Once you know what IP address(es) are being used for DNS queries, it is possible to test them individually.

But this is getting quite technical: really, this is EE's problem to diagnose and fix. And that's where you find out what their customer service is like.

And that's where you find out what their customer service is like.

This is one I already knew the answer to …

The reported issue has, apparently, resolved itself.

Web pages now resolve themselves quickly, the ‘hanging’ we were experiencing mysteriously vanished.

Thanks for everyone’s input.