[参考译文] DP83630：PTP 1STEP 错误 UDP 校验和

Alexey、您好！

感谢您跟进此问题。

[quote userid="620385" url="~/support/interface-group/interface/f/interface-forum/1463829/dp83630-ptp-1step-wrong-udp-checksum 我的问题是、DP83630是否有可能出于某种原因修改同步数据包的原始校验和？ PTP_TXCFG0寄存器的位15的说明表明"将重新生成 UPD 校验和和 CRC 字段"。[/QUOT]

根据我的理解、DP83630会修改与插入 PTP 帧中的时间戳数据相关的原始校验和。

在原始线程中、您注意到此问题每几百个数据包发生一次。 您是否发现新器件的故障率相同(独立于 IPG 配置)？

谢谢！

Evan

尊敬的 Evan：

根据正常的1SYNC DP83630操作、它会修改数据包中的最后两个填充字节、以保持原始校验和正确(在插入时间戳并修改最后两个字节之后)。  

关于错误的校验和问题、我认为它的故障率与以前相同。 仅当数据包的最后一个字节(最后一个填充字节)为0xFF 时才会失败、但并非所有最后一个填充字节设置为0xFF 的数据包都失败。 我还没有尝试 IPG 配置、因为我认为如果我使用不同的以太网控制器、遇到同样的问题将很奇怪。  

无论如何、我们发现一些商业产品(启用 PTP 的路由器配置为 PTP 从站)如果我们在同步数据包中具有额外的两个字节、则拒绝在主模式下连接到我们的器件。 所以我们必须另一条路由–禁用 UDP 校验和。 此处是我之前介绍过的另一个问题-禁用 PTP4L 套接字中的 UDP 校验和并清除 PTP_TXCFG0的第9位不足以获取 UDP 校验和设置为零的同步数据包(而发送其他 PTP 数据包时的 UDP 校验和设置为零)、只有禁用硬件校验和卸载模式(通过 ethtool)才会使内容按预期工作(所有 PTP 数据包通过 UDP 校验和设置为零时发送)。 接下来、我的问题是、DP83630可能会出于某种原因修改原始的 UDP 数据包校验和(在 UDP 标头中、而不是最后两个字节中)、还是应该深入探究以太网驱动程序或 MAC？

谢谢！

Alexey。

Alexey、您好！

很抱歉造成此处的混淆、我同意在1SYNC 操作中插入最后两个填充字节后预期原始校验和是正确的。

PHY 不应修改此内容、因此可能会导致 PHY 驱动程序异常或 MAC 行为。

是否可以与通过/失败的数据包共享.pcap、以便我进行审阅和进一步理解？ 我现在正在研究 DP83640驱动器。

谢谢！

Evan

尊敬的 Evan：

我有这样的文件要共享。 我如何分享它？ 似乎论坛仅支持音频或视频文件...

Alexey。

Alexey、您好！

请通过电子邮件 e-mayhew@ti.com 分享 。

谢谢！

Evan  

尊敬的 Evan：

已向您发送电子邮件。 请在接待处确认。

谢谢！

Alexey。

Alexey、您好！

谢谢、我收到了此文件。 我正在与团队讨论此处可能的原因、将通过反馈进行跟进。

此致、

Evan

Alexey、您好！

一个后续问题–在禁用 PTP 时间戳时、您是否发现有类似错误率的数据包问题？

我想避免数据包由于信号完整性或主机的某项设置而损坏。

谢谢！

Evan

Alexey、您好！

我认为、由于在帧中插入了额外的数据、这是 IPG/吞吐量利用率的一个问题。 如果正常帧的吞吐量为100%、则在每个帧中插入额外数据的情况下保持该吞吐量可能会导致错误(每 x 个周期切断页眉/页脚数据...？)

这些测试期间是否以100%的吞吐量？

请测试这两种情况并注意故障率的任何差异：

1)降低吞吐量

2) 2)增加 IPG

谢谢！

Evan

尊敬的 Evan：

测试期间的吞吐量几乎为零、仅限 PTP 数据包。 我曾尝试降低 PTP 数据包速率、它或多或少地将错误率降低了相同的值。  

问题、我们将尝试报告给您。

Alexey。

Alexey、您好！

感谢您的澄清。

在处理 IPG 测试用例时、我将尝试在我们的 EVM 上进行复制。

谢谢！

Evan