为什么以太网使用 CRC-32 而不是 CRC-32C？答案

【问题标题】：Why Ethernet is using CRC-32 and not CRC-32C?为什么以太网使用 CRC-32 而不是 CRC-32C？
【发布时间】：2019-07-23 17:11:51
【问题描述】：

已证明 CRC32C 提供比 CRC32 更好的结果（改进的汉明距离和更快的实现）。为什么以太网仍然使用旧的 CRC 32 而不是 CRC32C？

【问题讨论】：

可能是遗留问题。在为以太网选择 CRC32 时，检查长度为 n 的消息中所有可能的 k 位错误模式以确定最佳 CRC 可能会花费过多的计算时间。请注意，仍在对 32 位和更大的 CRC 进行研究，以寻找最佳和最小数量的多项式。

【解决方案1】：

“更快的实现”不适用于通常用于实现数据链路层的硬件。

您可能指的是一个特定的处理器架构 x86-64 具有使用 CRC-32C 多项式的 CRC 指令这一事实。然而，ARM 架构 (aarch64) CRC 指令使用 CRC-32 多项式。去图吧。

有人可能会争辩说应该使用另一个多项式，因为 Koopman 已经描述了许多多项式的性能，其性能比您提到的任何一个都好。但这些都不重要，因为......

所有传统硬件都必须支持原始 CRC，并且几乎没有动机提供备用 CRC，因为需要在发送器和接收器之间以某种方式协商。典型的噪声源没有明显的性能优势，这是罕见的单比特错误。

【讨论】：

我怀疑任何现实世界的以太网 MAC 都不会在硬件/hdl 中计算 CRC，因此 CPU 性能并不重要。 CRC 在 hdl 中相对便宜，在 CPU 指令中相对昂贵。（除非 CPU 有专用的 CRC 指令。）
我认为它可能存在明显的性能问题，而是在 WiFi 等嘈杂的技术中。
@user3563894 不，WiFi在物理层使用纠错码。
@MarkAdler - pclmulqdq + xmm 也可以用于 64 位 CRC，但我没有对此进行调查。
感谢您的结果！我期待 crc32 指令会比使用 pclmulqdq 折叠快很多。事实上，它的速度大约快了五倍。至于值，它加速了gzip解码，它越快，它对总cpu时间的贡献就越小。