Grain connect FTTP gone nuts

Hi all.

So we switched from virgin to grain about 3 weeks ago and we have started having issues.

If you guys can shed light on what happening that would be great.

The issue is low level packet loss and erratic latency.

Here is a link to my live BQM...

https://www.thinkbroadband.com/broadband/monitoring/...

I have phoned them but they just fob me off and say it's fine.

When we first started off with them latency was rock solid, but we have had two complete dropouts and now this.

Is a minor amount of packet loss normal on FTTP?

The odd thing is if I run ping in cmd prompt the latency looks fine.

Any help would be much apricated.

Oh and here is a snapshot from yesterday..

https://postimg.cc/4nDZM8bv

Ideally there should be no packet loss on any network connection and certainly for the BQM tests of a few packets a minute that shouldn't be seeing packet loss.

What you seem to have is evening time congestion, so some part of their network is running hot with not enough capacity, and that will see the latency and average latency rise along with some or a lot of packet loss.

Agreed. Classic peak time congestion causing highly variable latency due to queuing delays (yellow/blue) and measurable packet loss (red at the top). With packet loss of 1% of more, TCP slows down dramatically. Try a single-threaded speedtest to a site in Europe or USA to see what I mean.

Basically, they are running a poop network, with one or more links saturated.

Check for any service guarantees or exit clauses in your contract. Threaten to link to your graphs from a Trustpilot review, since they clearly demonstrate that their network is pants.

Thanks guys.

Yeah I have to agree it looks like congestion. The problem is I'm out if the 14 days cooling off period AND they haven't even completed the port of my landline yet!

I guess I'll have to wait for the number to be ported then make a formal complaint in the hope they'll release me from the contract.

I really wanted them to not be pants too.

Edited by risc19 (Wed 01-Nov-23 19:13:40)

In reply to a post by candlerb:

Agreed. Classic peak time congestion causing highly variable latency due to queuing delays (yellow/blue) and measurable packet loss (red at the top). With packet loss of 1% of more, TCP slows down dramatically. Try a single-threaded speedtest to a site in Europe or USA to see what I mean.

Basically, they are running a poop network, with one or more links saturated.

Congestion was my thought. Given the manner in which they are deploying their network, loads of small patches of coverage all over the place, I would be far from surprised if the OP's connection is backhauled by a gigabit EAD or equivalent. I'm reminded of a picture of an altnet's cabinet showing them selling gigabit service via a gigabit EAD.

You aren't going to be able to say this:

Independent benchmarking also shows our network deployment costs to be the lowest in the industry, giving us a strong competitive position.

While running a point to point own-duct network without some 'economies'. Even hyper-local cherry-picking of properties with the smallest possible frontage will only get you so far.

The steepness of the spikes and how intermittent they are makes me think the congestion is pretty local, too.

Can I ask what city your in?

Im waiting for them to finalise the network here (carlisle, new harraby area) and am considering them.

Sure, I'm in Reading in Berkshire.

You know, the really odd thing is that I can completely switch off the router yet here are no drop outs on the BQM.

So I thought... oh the little ONT is doing it but with grain the ONT looks more like its just a sort of spool for the optical cable,. It goes on optical and exits optical then directly into their router. No power source for the 'ONT'.

I phoned them today about the latency. Despite being a very helpful and knowledgeable man he was unable to find what's going on. He checked for excess traffic over all last night and it was normal.

The really nutty thing is that actually on my computer running ping from command prompt ping is low and stable.

Its almost like their server just 'delays' the echo request.

Example:

Pinging 212.58.235.129 with 32 bytes of data:
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59
Reply from 212.58.235.129: bytes=32 time=5ms TTL=59

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

I just ran that, yet right now my BQM is showing a minimum latency of 160ms!
I'm confused.

If you can turn off the router and are not seeing any drops then I would suggest you are not testing your own connection.

Where did you the get the IP address to ping?

Not sure how Grain connect you, put it is possible you are behind CGNAT, and the IP address you are pinging is one of their routers handling a lot of their customer connections, this will likely be set to respond to pings with low priority and would explain why it takes longer to respond when its busy at peak times.

Yes that would explain why it takes longer, it doesn't explain why that started only in the last few days.

It was just fine before.

The address was found automatically by think broadbands webpage, would it be a better test to try it with the WAN IP address?

I'll try it.

Edited by risc19 (Thu 02-Nov-23 18:11:01)

Grain do use CGNAT, they have said i can can have a static ip as i believe i will have issues accessing my ip security cameras. They mentioned a £5 per month charge for that which im ok with.

so would the graph be from the system that's routing traffic instead of their own personal connection?

sorry im not trying to hijack but as someone considering them as well one of the things i will want running is my own BQM at least for the first few month so am quite interested in this thread.

Tried a graph for IP address as indicated in router menu: Didn't respond to echo request.

Tried a graph for default gateway as indicated in router menu: Didn't respond to echo request.

Tried every damned ip address I could find.

Doesn't look like I can use a bqm for just my connection.

Feel free to hijack!

Maybe their router has the respond to ping on the wan port blocked?

according to the help files you can request access to the admin panel which also gives you things like light levels, ect.

Maby worth a ask?

Im planning on using a tp-link ax73, they said they will set the modem to bridge mode once installed.

Already have access.

There is no option for respond to ICMP Echo Request from WAN.

I looked everywhere.

Your earlier post suggesting that the BQM is unaffected by you powering off your router suggests that you are behind a CGNAT gateway; you're not measuring the quality of your connection but notionally the connection between TBB and Grain's CGNAT gateway. However it's usual practise for devices such as these to deprioritise or drop replies to pings at time of higher load

This also means that the "WAN" port on your router won't have a public reachable IP address, hence not being able to set up a BQM to your connection

If the WAN address on the router starts 100, 172, 10 or 192.168 it's a good bet that this is the case.

I would not rely on a BQM to the provider's CGNAT gateway to provide any indication of connection quality!

Random question, and of no help to the thread …

Based on your username and you saying Reading, some association with the cafe and shop on London St ? Worked there a couple of times back in the day.

Nice place.

In reply to a post by risc19:

You know, the really odd thing is that I can completely switch off the router yet here are no drop outs on the BQM.

Maybe you are behind CGN then? In which case BQM is pinging the NAT box rather than your line.

If you query the router, does its WAN IP address match the public IP address that the rest of the internet sees? (e.g. as shown by "ip4.me")

If it's different, especially if it's 100.64.0.0 to 100.127.255.255, then you're behind CGN.

If they match, you *could* still be behind some CGN address sharing with different port ranges for different customers. That's harder to test for.

Of course, if you're able to make inbound connections to your public IP, then you're definitely not behind CGN.

I'm on grain in a different city (NE) my graph shows the same latency around the same time

900/900 with static ip

Edited by browney (Fri 03-Nov-23 11:38:18)

In reply to a post by candlerb:

In reply to a post by risc19:

You know, the really odd thing is that I can completely switch off the router yet here are no drop outs on the BQM.

Maybe you are behind CGN then? In which case BQM is pinging the NAT box rather than your line.

If you query the router, does its WAN IP address match the public IP address that the rest of the internet sees? (e.g. as shown by "ip4.me")

If it's different, especially if it's 100.64.0.0 to 100.127.255.255, then you're behind CGN.

If they match, you *could* still be behind some CGN address sharing with different port ranges for different customers. That's harder to test for.

Of course, if you're able to make inbound connections to your public IP, then you're definitely not behind CGN.

Then yes I am behind a CGN.

In reply to a post by browney:

I'm on grain in a different city (NE) my graph shows the same latency around the same time

900/900 with static ip

That's very useful info, thanks.

It least I know it's not local.

In reply to a post by Zarjaz:

Random question, and of no help to the thread …

Based on your username and you saying Reading, some association with the cafe and shop on London St ? Worked there a couple of times back in the day.

Nice place.

Nope, sorry but I do know the place you are talking about.

Small world eh?

Small world eh?

Yes indeed.

I've also noticed degraded performance on some video streaming services during these times of high latency on the graph but turning a VPN on solves this.


Some sort of traffic management? I didn't expect VPN to solve this.