FTTP Packet Loss

So seeing some packet loss on my shiny new FTTP connection, I understand packet loss of any kind is no good. I have not say I am not seeing anything negative related this (that I have noticed anyway).

My Broadband Ping

I am seeing smaller spikes throughout the day but mostly this is happening between 8am - 10pm.

There is an Openreach Engineer booked for tomorrow.

There is an Openreach Engineer booked for tomorrow.

Errrm …. what do you think the engineer will be able to do ?

They will check the light loss readings, and insure they are within parameters. They *might* connect their laptop direct to your ONT and do so co-op testing.

How is this fault affecting your service ?

You’ve asked the first question and then proceeded to answer it? I wouldn’t have known how the OR engineer would have diagnosed the issue but I am assuming it would have been the first step to check the local infra?

To your second question I am actually not “aware” of any adverse effects on the connection if I am honest.

I setup the BQM noticed it, confirmed it with f8lure as well, reported it to Aquiss and received a text today to say that an openreach engineer would attend tomorrow.

I can only assume Aquiss have run a test that's reported something like the light levels out of range, it would be very unlike them to just book a engineer and risk the charge for a fault outside the Openreach network.

I have a minor number of ping replies missing on my BQM through the day, but I have pretty good response time through most of the day.
However a little while back I tried three different routers on my fttp line (a plusnet hub2, tp-link vr600 and a synology wrx560.) They each showed noticeably different BQM graphs on the same line...
using the internet I didn't notice any difference with each router, The synology has the worst dropped pings (a bit like yours but a few more, but that's the one I decided to stick with as the difference only shows on the BQM graphs, the synology runs a media server and a couple of other things and lets me configure VLANs - so it's probably busy at times and sees the pings as a low priority.

The best looking BQM graph came from the old TP-Link VR600.

So you just need to be aware of what you are measuring and it could be your router that is dropping the packets and your internet connection is working well.

I guess thats a potential cause.. I am using a UCG-Fiber so it should be handling the ping request and its not under any heavy load.

Aquiss have said they run a line test and it was the test that recommended an engineer so think there is something that may not be quite right.

The Openreach engineer has attended and feels everything in the property looks good, however he did mention there where BIP errors and said that it could be a faulty or loose SPF connector at the exchange (there has been a batch of them recently apparently) so he is going to go ahead and re-seat or change it or something.

Here's my current BQM FYI... https://www.thinkbroadband.com/broadband/monitoring/...

Can't see an easy way to share the older graphs from the other routers. The Plusnet Hub2 didn't have any dropped pings but response times varied a lot and the tp-link had no dropped pings and similar response times to the synology.

Would be interested to hear how you get on and if they find any issues on your connection.... Thanks

Aquiss have said they run a line test and it was the test that recommended an engineer so think there is something that may not be quite right.

So LTOK/customer apparatus then ? They wouldn’t have booked an appointment against a test result that showed an external issue.

In reply to a post by SamBGB:

The Openreach engineer has attended and feels everything in the property looks good, however he did mention there where BIP errors and said that it could be a faulty or loose SPF connector at the exchange (there has been a batch of them recently apparently) so he is going to go ahead and re-seat or change it or something.

...will be bit errors rather than BIP errors.

If it was in the exchange at the OLT, then it would also be affecting all other customers on that PON - though it may not be reported / checked.

Last message from OR engineer….

Hi. SFP has been replaced - all connections cleaned - hopefully it will work as it should and errors will disappear.

So far BQM looks clean since his message.

Edited by SamBGB (Sat 16-Aug-25 09:16:57)

Looks like this resolved the issue no longer seeing packets dropped.

In reply to a post by Pheasant:

In reply to a post by SamBGB:

The Openreach engineer has attended and feels everything in the property looks good, however he did mention there where BIP errors and said that it could be a faulty or loose SPF connector at the exchange (there has been a batch of them recently apparently) so he is going to go ahead and re-seat or change it or something.

...will be bit errors rather than BIP errors.

If it was in the exchange at the OLT, then it would also be affecting all other customers on that PON - though it may not be reported / checked.

No, he meant BIP. Bit Interleaved Parity. They will of course produce bit errors but BIPs are what count up when there's an issue with the optical section.

Everyday is a school day as they say 😀

It must be nearly 30 years since I last used a BERT in anger, during a gap in study / leave whilst working in the datacentres of Reuters.

In reply to a post by SamBGB:

Last message from OR engineer….

Hi. SFP has been replaced - all connections cleaned - hopefully it will work as it should and errors will disappear.

So this replacement is not in your equipment, but presumably somewhere at the other end of the fibre?

Thats correct.

The notes on the job:
Issue caused by wear and tear on the connector port at the AGG-Node; resolved by cleaning the port.

In reply to a post by SamBGB:

Thats correct.

The notes on the job:
Issue caused by wear and tear on the connector port at the AGG-Node; resolved by cleaning the port.

Earlier in the thread you said

The Openreach engineer has attended and feels everything in the property looks good, however he did mention there where BIP errors and said that it could be a faulty or loose SPF connector at the exchange (there has been a batch of them recently apparently) so he is going to go ahead and re-seat or change it or something.

But, as a rule, the agg node will be out on the highways and byways somewhere, not in the exchange. I wonder where the truth actually lay ?
It would be fairly unusual for the common or garden engineer to be ferreting about in either the agg node or the head end.

Glad it got sorted though, and thank you for updating the thread.

It’s a very inconsistent explanation. At one point there was talk of an SFP problem in the exchange. OK fair enough, must be rare but not impossible.

Then it transpires that something was amiss at the aggregation node. Except there are no connectors (or any actives) to be loose, dirty or faulty there, just splicing…weird. The engineer that attends your house isn’t going to re-splicing anything at an AgNode or playing about with actives on the OLTs. The latter usually takes more than a few days or more to get booked in etc.

At least the OP is sorted, but the explanation is v. opaque.

Edited by Pheasant (Mon 18-Aug-25 14:38:25)

In reply to a post by Pheasant:

It’s a very inconsistent explanation. At one point there was talk of an SFP problem in the exchange. OK fair enough, must be rare but not impossible.

Then it transpires that something was amiss at the aggregation node. Except there are no connectors (or any actives) to be loose, dirty or faulty there, just splicing…weird. The engineer that attends your house isn’t going to re-splicing anything at an AgNode or playing about with actives on the OLTs. The latter usually takes more than a few days or more to get booked in etc.

At least the OP is sorted, but the explanation is v. opaque.

Send three and fourpence, we are going to a dance.

In reply to a post by rippedcotton:

In reply to a post by Pheasant:

It’s a very inconsistent explanation. At one point there was talk of an SFP problem in the exchange. OK fair enough, must be rare but not impossible.

Then it transpires that something was amiss at the aggregation node. Except there are no connectors (or any actives) to be loose, dirty or faulty there, just splicing…weird. The engineer that attends your house isn’t going to re-splicing anything at an AgNode or playing about with actives on the OLTs. The latter usually takes more than a few days or more to get booked in etc.

At least the OP is sorted, but the explanation is v. opaque.

Send three and fourpence, we are going to a dance.

What did you mishear Brian ?

In reply to a post by Pheasant:

Everyday is a school day as they say 😀

It must be nearly 30 years since I last used a BERT in anger, during a gap in study / leave whilst working in the datacentres of Reuters.

We're old :'(

In reply to a post by Bam16:

I have a minor number of ping replies missing on my BQM through the day, but I have pretty good response time through most of the day.
However a little while back I tried three different routers on my fttp line (a plusnet hub2, tp-link vr600 and a synology wrx560.) They each showed noticeably different BQM graphs on the same line...
using the internet I didn't notice any difference with each router, The synology has the worst dropped pings (a bit like yours but a few more, but that's the one I decided to stick with as the difference only shows on the BQM graphs, the synology runs a media server and a couple of other things and lets me configure VLANs - so it's probably busy at times and sees the pings as a low priority.

The best looking BQM graph came from the old TP-Link VR600.

So you just need to be aware of what you are measuring and it could be your router that is dropping the packets and your internet connection is working well.

I was about to say we've seen people have problems with Synology routers, then realised that was you

In reply to a post by Zarjaz:

In reply to a post by rippedcotton:

In reply to a post by Pheasant:

It’s a very inconsistent explanation. At one point there was talk of an SFP problem in the exchange. OK fair enough, must be rare but not impossible.

Then it transpires that something was amiss at the aggregation node. Except there are no connectors (or any actives) to be loose, dirty or faulty there, just splicing…weird. The engineer that attends your house isn’t going to re-splicing anything at an AgNode or playing about with actives on the OLTs. The latter usually takes more than a few days or more to get booked in etc.

At least the OP is sorted, but the explanation is v. opaque.

Send three and fourpence, we are going to a dance.

What did you mishear Brian ?

That no one seems able to determine where the problem lay.

The types of errors are unlikely to be due to poor light levels or reflections etc. It's more indicative of a failure of an active (electronic or optoelectronic) component which points to the exchange equipment and quite likely the pluggable module on the OLT line card which send/receive the optical signal on the particular passive network which serves the OP.

The subsequent explanation suggesting "wear and tear on the connector port at the AGG-node; resolved by cleaning the port." make little to no sense - as that simply doesn't exist in the Openreach FTTP world!!

I suspect somewhere a note has been misquoted/noted or someone is getting jobs confused or is under the influence of mushrooms....

I'm always willing to be enlightened however 😅

Edited by Pheasant (Tue 19-Aug-25 15:39:16)