do FEC and CRC Errors correlate to inconsistent ping?

Question

I am subscribed to VDSL2 plan with 10/1 Mbps (down/up). My line stats seems to be decent, but I noticed some reported CRC and FEC errors as shown:

On the other hand, in online games I notice some slight variation in ping times even though I am the only one using internet with Ethernet cable, so is there any correlation between Line errors and ping stability? I read that CRC and FEC errors are error coding protocols that help correct line errors on DSL connections, and high errors count can drop down bandwidth and possibly cause disconnection, so does it make sense then?

Solution 1

Is there any correlation between Line errors and ping stability?

Yes.

• CRC errors mean that packets have to be re-transmitted.

• FEC errors don't affect line speed, but indicate that "the Interleaving & Error Correction process is working and doing what it should".

Having said that you only have a very small number of CRC errors (11 in over 6 hours) which shouldn't really affect your line speed or ping times at all.

CRC Errors - Cyclic Redundancy Check

Count of CRC errors. CRC is an error detection code used to verify packet transmission between the sender and receiving end. A CRC error indicates that part of the data packet is corrupt and requires re-transmission. - see Cyclic Redundancy Check (CRC) for a more in depth explanation.

Many CRC errors in a short period of time will show a noticeable reduction in throughput speed. This can be an early indication that there is too much noise on the line and in extreme situations can lead to loss of sync (disconnection with the exchange).

FEC Errors - Forward Error Correction

Count of errors that have been corrected due to error correction being applied to the line. Error correction is turned on at the same time as Interleaving. Its normal to see FEC errors on an Interleaved line and rather than anything to be too concerned about its more an indication that the Interleaving & Error Correction process is working and doing what it should. - See Error Correction for more information.

(emphasis mine)

Source Kitz - Linestat parameters & counters

Solution 2

"Ping times", aka "latency" can be introduced into a system by many factors, and yes, CRC errors can be a cause.

A CRC (Cyclic redundancy check) error results in a dropped packet - it simply disappears. All the system knows is that the packet is corrupt, so there is no way to request a re-transmission for any specific packet, and there is no mechanism to handle this.

A major feature of TCP is that it provides a "perfect connection" between two applications. Thus, when using TCP, the missing packet is detected and a re-transmission is requested. This can take some time to occur, depending on the activity of the connection.

When using UDP (often used for games), or other unreliable protocols like ICMP (used by ping), there is no way to determine that a packet is missing without the higher level protocol or application being designed to expect it / handle the potential loss. In these cases, the missing data is just forgotten, and the application moves on. This can result in "lag", and can be observed as players moving in a jerky manner.

---

FEC (Forward Error Correction) is not typically a cause of noticeably higher latency. It indicates that the link has corruption, but this corruption has been detected, and the data corrected.

Comments

[user253751]

There's always a slight variation in ping times.

[tuki]

Great answer. So I should more worried about CRC errors count than FEC because it causes line re-transmit which is the main cause of packet loss, or at least jittery ping. Correct?

[DavidPostill]

@tuki If the re-transmit succeeds there is no packet loss. Packet loss is normally caused by one or more of 1/ Link Congestion 2/ Poor Device (Router/Switch/Firewall/etc.) Performance 3/ Software issues (bugs) on a network device or 4/ Faulty Hardware or Cabling. See 4 Causes of Packet Loss and How to Fix Them for more info.

[DavidPostill]

Use pathping to pinpoint packet loss between you and the target location.

[tuki]

I understand, then the re-transmit of packet/s would cause slightly high ping at best if done properly?

[DavidPostill]

See my answer Game latency increases during day, not shown in ping command

[DavidPostill]

@tuki It depends on what percentage are re-transmitted. In your case 11 in over 6 hours is effectively zero. If there were many thousands in a 24 hour period then you would have noticeable problems.

[tuki]

Thank you so much for the detailed answer. Last question, do you think I would encounter that CRC error during my busy time? according to my line stats, only 11 downstream CRC over past 7~ hours were detected. Is this considered good or bad?

[Tim_Stewart]

@tuki, compared to the DSL service we had here years ago. It's good, this isn't just your homes lines. It's all the cross-connects back to the DSLAM on the local loop. There are alot of places where interference, noise, and signal loss can be introduced even in the last mile.(which I'm guessing you are not in) or you would be offered much higher speeds.

[Attie]

As David said, 11 errors in 6 hours is negligible.

[Jörg W Mittag]

ping uses neither UDP nor TCP, it uses ICMP, which is not a reliable protocol, there is no re-transmission.

[Jörg W Mittag]

ping uses ICMP, which is not a reliable protocol, there is no re-transmission (unlike e.g. TCP).

[Attie]

Indeed... I added a bit too cover that too.