FECおよびCRCエラーは一貫性のないpingと相関していますか？
10/1 Mbps（ダウン/アップ）のVDSL2プランに加入しています。私の回線統計はまともなようですが、いくつかの報告されたCRCとFECエラーが示されていることに気づきました：
一方、オンラインゲームでは、イーサネットケーブルを使用するインターネットを使用しているのは私だけですが、ping時間にわずかな変動が見られます。したがって、回線エラーとpingの安定性には相関関係がありますか？ CRCとFECエラーはDSL接続の回線エラーを修正するのに役立つエラーコーディングプロトコルであり、エラー数が多いと帯域幅が低下し、切断が発生する可能性があることを読みました。それでは意味がありますか？
ラインエラーとpingの安定性の間に相関関係はありますか？
はい。
CRCエラーは、パケットを再送信する必要があることを意味します。
FECエラーは回線速度に影響を与えませんが、「インターリーブおよびエラー訂正プロセスが機能しており、本来の動作を行っている」ことを示しています。
CRCエラーの数はごくわずか（6時間以上で11）であり、回線速度やping時間にまったく影響を与えないはずです。
CRCエラー-巡回冗長検査
CRCエラーの数。 CRCは、送信側と受信側の間のパケット送信を検証するために使用されるエラー検出コードです。 CRCエラーは、データパケットの一部が破損しており、再送信が必要であることを示します。 -より詳細な説明については、 巡回冗長検査（CRC） を参照してください。
短期間に多くのCRCエラーが発生すると、スループット速度が著しく低下します。これは、回線にノイズが多すぎることを早期に示している可能性があり、極端な状況では同期が失われる（交換機との接続が切断される）可能性があります。
FECエラー-前方誤り訂正
行に適用されているエラー訂正のために訂正されたエラーの数。インターリーブと同時にエラー訂正がオンになります。 インターリーブされた行にFECエラーが表示されるのは正常であり、インターリーブとエラー訂正プロセスが機能していることを示すことについてあまり心配する必要はありません。そして、それがすべきことを実行します。-詳細については、 エラー訂正 を参照してください。
（私の強調）
"Ping times"、別名 "latency"をに導入できます多くの要因によるシステム、そしてはい、CRCエラーが原因である可能性があります。
CRC（巡回冗長検査） エラーの結果、パケットがドロップされます-単に消えます。システムが認識しているのは、パケットが破損していることだけです。そのため、特定のパケットの再送信を要求する方法はなく、これを処理するメカニズムもありません。
TCPの主な機能は、2つのアプリケーション間に「完全な接続」を提供することです。したがって、TCPを使用する場合、欠落したパケットが検出され、再送信が要求されます。これは、接続のアクティビティによっては、発生するまでに時間がかかる場合があります。
UDP（ゲームでよく使用される）またはICMP（pingで使用される）などの信頼性の低いプロトコルを使用する場合、上位レベルのプロトコルまたはアプリケーションがパケットを予期するように設計されていないと、パケットが欠落していると判断する方法はありません。 /潜在的な損失を処理します。このような場合、欠落しているデータは忘れられ、アプリケーションは先に進みます。これにより、「lag」が発生する可能性があり、プレーヤーがぎくしゃくした動きをしているように見えます。
FEC（前方誤り訂正） は、通常、著しく高い遅延の原因ではありません。リンクに破損があることを示していますが、この破損が検出され、データが修正されています。