FTTH and fiber optic cable concern

Hello!

I just switched to an FTTH provider and I have a usual question about the fiber optic cables.

After the engineers installed the wall socket on the internal side of an external wall, I had to run 10 meters of fiber optic cable through an existing corrugated cable duct, in order to install the model in the designated location.

Due to the SC/APC connector, the cable got stuck and I had to pull it very hard to unstuck it (not very proud about it, but it was stuck middle way and at that point, I was aiming to remove it and use a new cable).

I was pretty sure the cable was compromised (no visual damage), but after testing the installation I get the same download/upload speeds (around 920-940 Mbps).

I might be overzealous here, but the one thing that leaves me dubious is that the ping (measured from the router) is higher by a very small fraction: before passing the wire I got 1.08ms on my second test, while today it is on average 1.70ms.

I appreciate the difference is insignificant and there are external factors, but given the problematic installation, I am concerned that the cable might have some damage.

What would be a sign of a compromised cable?
Is there any way to test the cables? Any tool I can buy?

I'd rather not run a new cable (if there is no evidence that this one is broken), as it was a traumatizing experience!

Edited by ronald23 (Sat 18-Feb-23 10:55:49)

Ping times vary anyway and that's not necessarily your own SC/APC extension cable at fault (presumably that's what you installed - rather than what was installed by the provider).

As long as the PON light on the ONT is solid, then you are good to go really. If there was a break or over-bend in the fibre it would simply lose too much light and not work.

You can test them with a light source and power meter (or an OTDR !) but in reality one would simply replace it for a new one as they are only a couple of quid.

Spend your money on a cable pulling course.

The only times you would snag on corrugated conduit is with very tight bends and a rigid cable or if pulling with the front tip of the cable offset.

Ideally one does not pull a connectorised fibre cable through any sort of conduit 😅 or indeed if the fibre cable is single-ended (like say an Openreach inside/out cable from the CSP) then pull the raw end and not the end with the connector.

They’re simply not designed for this.

And hence my first comment!

Maybe you should have run "10 metres of fibre ".

Totally agree with your original comment, if the connector is snagging then its either got bends that are to tight or there is some form of user mis-op.

A faulty cable or connector will result in dropped packets and/or dropped connections. So if you want to be sure you need to monitor the interfaces at either side of the cable. Most OSes allow monitoring of network interfaces to show dropped packets, retry packets, retranmissions, etc. Another option is to run ping for 24hs with a large packet size (ie ping -s 4096 [ip]) and then look at the packet loss. However the latency differences you have are expected, specially with consumer grade hardware.

In reply to a post by GreenLantern22:

A faulty cable or connector will result in dropped packets and/or dropped connections. So if you want to be sure you need to monitor the interfaces at either side of the cable. Most OSes allow monitoring of network interfaces to show dropped packets, retry packets, retranmissions, etc. Another option is to run ping for 24hs with a large packet size (ie ping -s 4096 [ip]) and then look at the packet loss. However the latency differences you have are expected, specially with consumer grade hardware.

Thanks - this is very helpful.

I haven't noticed any packet loss or increased jitter, but I haven't measured it on an extended window as you recommend. Will do.

There is no sign of compromised cable, besides my concern.

Again - the only reason for not changing the cable is that it is a very tricky setup and I am not keen to redo it again.

In reply to a post by MHC:

Spend your money on a cable pulling course.

The only times you would snag on corrugated conduit is with very tight bends and a rigid cable or if pulling with the front tip of the cable offset.

As I said, it wasn't my proudest moment. I had to rush and the corrugated has a compressed section, where the connector got stuck.

Unfortunately, I don't have the equipment to make a cable myself, hence I was passing the wire with the connector. Appreciate this shouldn't be done.

Anyway, if I need the pass another wire I have not learned that it is enough to remove the movable part of the the connector to make it flow without getting stuck in my wall

I would take the advice from Greenlantern22 with a huge pinch of salt.

If your fibre is damaged your FTTP service is very likely to fail completely. generally FTTP works or it doesn't.

I don't believe running tests for dropped packets or extended ping tests will achieve anything. If your service is working just accept that it is OK, ping times can vary so a change of less than 1mS is nothing to be worried about.

In reply to a post by Realalemadrid:

I don't believe running tests for dropped packets or extended ping tests will achieve anything. If your service is working just accept that it is OK, ping times can vary so a change of less than 1mS is nothing to be worried about.

I would note that even in a fancy high-end 10Gbps+ local Ethernet network complete with DCB enhancements (https://en.wikipedia.org/wiki/Data_center_bridging) you get variations in ping times of up to 0.25ms so 1ms on a WAN link is neither here nor there.

ronald23

There is no way that what you have done would affect the ping. This is based on the time it takes for the light and electronics to get a packet from a to b. If you have affected the cable in any way you would be getting lower speeds (or none at all) rather than a tiny increase in ping.

Is it possible to have single dropped pings here and there on GPON anyway? I thought there was a handshake process involved and if the link was intermittent you'd lose the connection entirely and have to wait for it to establish again.