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)