This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DP83640: DP83640

Part Number: DP83640

Hi, We configure the DP83640 in TS_APPEND mode(TS_APPEND & TS_INSERT = 1 in PTP Receive Configuration Register 3). My customer use heavy multicast for PLC communication with our PTP ethernet switch(2-step P2P Layer 2 TC mode). They reported the multicast packet loss occur. We reconfigured the DP83640 to use  PTP Receive Timestamp Register(TS_APPEND & TS_INSERT = 0). The customer reported no packet loss occur. Is this is chip limitation or bug ? Is there any work around for the issue ? Thanks.

  • Hi Tom,

    Is the issue only occurring for multicast?
    Have you tested on unicast and broadcast?
    How does wireshark look when you see the errors and when you do not?
    Are the frames completely corrupted?
  • Hi Ross,
    It occurs on multicast, broadcast & unicast. We replayed the captured multicast packets by our customer and check on the receiver side. The packet loss always happen, but just the loss amount is different. I find the description in the datasheet - "Enabling IEEE 1588 Receive Timestamp insertion will increase the Receive Data Latency by 40 bit times ". Could the insertion/append process cause the packet loss ? Any suggestion to avoid the issue ? Thanks.
    Tom Ko
  • I am not aware of packet loss with it enabled. is the packet completely lost or just corrupted?
    What does the packet look like when you capture it on wireshark?
  • Hi Ross,

    I used 2 switches connected. Each of the switch connects a NB. One NB sends multicast packets(01-00-5E-7F-00-04) in the rate about 1000 pkts/sec, the other NB receives these packets. The switches run 2-step P2P TC mode. The receiving side will lose a few multicast packets. The loss rate depends on the PTP event message between the 2 switches. I did 10 time tests. The packet loss occurs about 80%. When I reprogramed the switch to not using TS_APPEND & TS_INSERT mode(use PTP rx/tx queues). I also did 10 time tests and got no packet loss. Because the wireshark can not show the corrupted packets, I only see the packet loss on the receiving side(the receive count is less than transmit count).

    Tom

  • Hi Ross,

    I checked the configuration again. Because the TS_APPEND mode is used, I configured the PTP_RXCFG3 TS_MIN_IFG(bit 15:12) from 12 to 7. I tested again but got the same lost packet result. Do you have any update on the case ? Thanks.

  • Hi Tom,

    The frames that are lost, are they of a certain length?
    Is there a utilization rate dependency on the loss?
    Have you tried reducing the utilization rate to get a longer IPG and see if the issue still occurs?
    I am trying to narrow down the issue.

    Best regards,
    Ross
  • Hi Tom,

    Any update?
  • Hi Ross,

    As I mentioned in the previous, I send the test traffic by a PC. The transmitting rate is not high. I find the adjustment of IPG in my previous test is wrong(change IPG from 12 to 5). Because the timestamp is 5 bytes and appended on the end of a PTP event message. The IPG should be adjusted from 12 to 17. And I need to adjust the IPG from the source - switch MAC. Unfortunately, the IPG in switch MAC only have 4 bits. That means the maximum IPG is 15 just like DP83640. I tested in 15 bytes IPG and still got packet loss(though the loss rate seems lower than previous). Is it right of my understanding ? Do you have any suggestions ? Thanks.

  • Hi Tom,

    For a valid IPG, there needs to by at min 0.96us = 12 bytes.
    I am not sure what you mean by the MAC only has 4 bits.
  • Hi Ross,

    Just like DP83640 PTP_RXCFG3 TS_MIN_IFG(bit 15:12). DP83640 only supports 4 bit inter-frame gap. The MAC I use has the similar register setting and support 4 bit inter-frame gap setting. When I use APPEND MODE, the 5 bytes timestamp is appended on the end of a PTP event packet. So the inter-frame gap become 12-5 = 7 bytes. The next packet needs to add more 5 bytes bit time to send out the next packet. That means the next packet needs 12+5=17 bytes inter-frame gap setting. But the inter-frame gap setting is a 4-bit register(max value is 15). It will cause the inter-frame gap of the next packet and the PTP event packet is less than 12 bytes. This could cause packet loss. This is my assumption. Do you have any solution for this ? Thanks.

    Tom

  • Hi Tom,

    To prove that this is the issue, can you delay the transmission of a frame or transmit at a lower rate?
    Right now it looks like you are trying to operate at full utilization with the risk of operating above full utilization.
    Can you scale back the transmission rate at all? The other thing to prove this out is to disable the append option and set the IPG below 12 bytes to see if the issue occurs like it does when append is enabled.
  • Hi Ross,

    I reduced the packet transmitting rate to 10 pkts/sec and got no packet loss. As I said before, I disable APPEND MODE and also got no packet loss. But in practical network, the inter-frame gap could be the minimum value - 12 bytes. In this situation, the APPEND MODE will have the change to cause the packet loss. Do you have any suggestion or work around for this issue ? Thanks.

    Tom

  • Hi Tom,

    I unfortunately do not have a solution for this. When you implement the application, you might need to increase your min IPG to account for a worst case where append occurs. The only method would be to use the TS_MIN_IFG (bits[15:12]), which you already tried. Can you increase TS_MIN_IFG to a value larger than 12? How is the result with that? You tried a smaller value.
  • Hi Ross,

    I have tried to configure the TS_MIN_IFG to the maximum value 15. But I still got packet loss(though the loss rate decrease a little bit). If there is no solution for this case, do TI have another chip can resolve the issue ? Thanks.

    Tom

  • Hi Tom,

    There is no other part with the 1588 support.
    There is no way for the MAC to ensure that the min IPG with an appended frame does not go below 12 bytes?