DP83630: PTP 1STEP wrong UDP Checksum

Hi Alexey,

Thank you for following up on this issue.

Alexey Tsirlin said:

My question is, is it possible that DP83630, for some reason, modifies the original checksum of SYNC packet? The explanation for bit 15 of PTP_TXCFG0 register states that "UPD checksum and CRC fields will be regenerated".

From my understanding, DP83630 will modify original checksum relative to timestamp data inserted into PTP frame.

In the original thread, you noted this issue occurs once every few hundred packets. Have you observed the same failure rate with new device, independent of IPG configuration?

Thank you,

Evan

Hi Evan,

According to normal 1SYNC DP83630 operation, it modifies the two last padding bytes in the packet to keep the original checksum correct (after inserting the timestamp and modifying the last two bytes). 

Regarding the wrong checksum issue, I think it has the same failure rate as before. It only fails if the last byte of the packet (the last padding byte) is 0xFF, but not all packets with last padding byte set to 0xFF fail. I didn't play with IPG configuration yet because I thought that if I use different Ethernet controller, it will be strange to get the same issue. 

Anyway, we have found some commercial products (PTP enabled router configurated as PTP slave) that refuses to connect to our device in master mode if we have those additional two bytes in SYNC packet. So we must go the other route - disabling the UDP checksum. This is where I got another issue that I have described - disabling the UDP checksum in PTP4L socket and clearing bit 9 of PTP_TXCFG0 is not enough to get SYNC packets with UDP checksum set to zero (while other PTP packets are sent with UDP checksum set to zero), only disabling the hardware checksum offload mode (through ethtool) makes things work as expected (all the PTP packets are sent with UDP checksum set to zero). From here comes my question, is there a possibility that for some reason, the DP83630 modifies the original UDP packet checksum (in UDP header, not the last two bytes) or should I dig into the ethernet driver or MAC?

Thanks!

Alexey.

Hi Alexey,

Apologies for the confusion here, I agree that the original checksum is expected to be correct after inserting the last two padding bytes in 1SYNC operation.

The PHY should not modify this, so there may be an anomaly with PHY driver or MAC behavior.

Is it possible to share .pcap with passing/failing packets so I can review and further understand? I am looking into DP83640 driver in the meantime.

Thank you,

Evan

Hi Evan,

I have such file to share. How can I share it? It seems that the forum only supports audio or video files...

Alexey.

Hi Alexey,

Please share over email at e-mayhew@ti.com .

Thank you,

Evan 

Hi Evan,

Sent you an email. Please confirm upon reception.

Thanks!

Alexey.

Hi Alexey,

Thank you, I received the file. I am discussing with the team possible causes here, will follow up with feedback.

Best Regards,

Evan

Hi Alexey,

One follow-up question - have you observed any packet issues with similar error rate when disabling PTP time stamping?

I would like to rule out the packet being corrupted due to signal integrity or some setting from the host.

Thank you,

Evan

Hi Evan,

Only 1Step SYNC packets are getting checksum wrong(the packets where DP83630 altering the data). It is also important to note that the packets are not getting corrupted, but the 2 padding bytes (or the timestamp itself, I cannot know) are wrong. I have compared the packet data before it gets to PHY and as it received on other end, and the data that is not altered by PHY itself (timestamp and padding) is the same.

Alexey.

Hi Alexey,

I believe this is an issue with IPG/throughput utilization due to additional data inserted in frame. If throughput is at 100% for normal frame, maintaining this throughput with additional data inserted in each frame may cause errors (header/footer data being cut off every x cycles...?)

Is throughput at 100% during these tests?

Please test for these two cases and note any difference in the failure rate:

1) Reducing throughput

2) Increasing IPG

Thank you,

Evan

Hi Evan,

The throughput is nearly zero during the test, PTP packets only. I've tried reducing the PTP packets rate, it reduced the error rate by the same amount more or less. 

Regarding the IPG, will try and report back.

Alexey.

Hi Alexey,

Thank you for clarifying.

While you work on IPG test case, I will look to replicate on our EVM.

Thank you,

Evan