• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 33 subscribers
  • Views 817 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

DP83TD510E: Motor control with 10Base-T1L 10M Single Pair Ethernet PHY

DP83TD510E: Network Jitter/Latency on SPE Link when running UDP Audio + TCP Video stream

Daniel Haddad
Intellectual 255 points
Part Number: DP83TD510E
Other Parts Discussed in Thread: DP83822I

Hi Ti Team,

We have developed a SPE to Ethernet Media Converter based on the DP83TD510E and DP83822i both operating as RMII Slave operating of a 50Mhz Oscillator.

JPerf tests show great data rates over both TCP and UDP ~ 9.5Mbs, no loss of packets and Network Jitter of ~ 2ms over a 1km line (CAT6 twisted pair)

Our application is using Audio UDP and Video streaming via TCP - UDP Audio packets are sent every 10ms at 160 Byte payload plus IP overhead.

We found that UDP Audio was fine although once we included the Video stream through the link our Audio was effected by packet to packet Jitter/Latency of ~ +/- 10-15ms observed in Wireshark and audibly noticeable.

Total Bandwidth being used didn't make any difference, initially we were using a total of 7mb/s, then we reduced it to a total of 2.7mb/s and the Jitter/Latency was still present.

Once we remove the video stream the Jitter/Latency results come good +/- 0.5ms.

If we removed the SPE Cards and replaced them with a Netgear 10/100mb Switch the Jitter/Latency results were also good with Audio+Video +/- 0.5ms.

Can SPE address anything around latency or is this addressed on other network layers I.e Application using buffering.

Wanted to confirm if there was anything we could check on our prototype design before we go to market.

Kind Regards, 

Daniel

  • 0
    TI__Mastermind 26772 points

    Hi Daniel,

    My first thought is that the physical layer should not care what type of data is going through it and this may be a layer 2 or higher issue (application layer). Do you know what is different between the audio and video packet structure? Is the Inter-packet gap different? 

    You mentioned the video bandwidth was reduced to 2.7mb/s but there were still issues. Can you reduce the bandwidth further? What is the mb/s with audio only?

    Do you think this may be a flow control issue?

    Can you share a block diagram of your setup? I am wondering how you replaced the SPE cards with the netgear switch, and if the link auto-negotiated to 100Mbps in that case and fixed the issue. 

    Thanks,

    David

  • 0 in reply to David Creger
    Intellectual 255 points

    Hi David

    Please find attached our Latency Test Setup Diagram with Wireshark Captures (With and without SPE media converters).

    Wireshark 'Delta Time' column added to for visibility of the 10ms UDP packets received. 

    Unfortunately i have the video feed running at the lowest resolution so 2.7Mb is the lowest i can go with these IP cameras.

    Keeping in mind the network switches used are unmanaged simple 10/100mb switches, can confirm that the Link between Switches without SPE does indeed Auto-Neg at 100mb.

    So more of a general question as to whether this is a limitation of the network when linking down at 10mb or the SPE to Ethernet Media Converter (DP83TD510E & DP83822i) and if there is anything we can improve or check on our design to reduce this latency/network congestion.

    Kind regards,

    Daniel

    Latency Test Setup.pdf

  • 0 in reply to Daniel Haddad
    TI__Mastermind 26772 points

    Hi Daniel,

    Can you try changing the video protocol to UDP?

    With the media converter in place, do you see any packet errors with the audio + video transfer? You can check this by reading register 0x15 on the DP83TD510.

    To answer your final question, we could determine this if you are able to force 10mbps on the switches. Is there a way to force the speed here?

    Thanks,

    David

  • 0 in reply to David Creger
    Intellectual 255 points

    Hi David,

    The IP Cameras are locked into TCP streaming protocol although happy to check register 0x15 for RX Error Counter.

    I've also found a Netgear Prosafe 108E switch here in the lab which allows speed control on the ports, so i can force the ports for 10M Full Duplex and re-test.

    Hopefully get around to this tomorrow and let you know on the results.

    Thanks again for your help.

    Kind regards,

    Daniel

  • 0 in reply to Daniel Haddad
    TI__Mastermind 26772 points

    Great, let me know the results.

    Thanks,

    David

  • 0 in reply to David Creger
    Intellectual 255 points

    Hi David,

    We've forced the switch to 10M and results were pretty good, not much variation between packets ~ +/- 1ms

    So this leaves us with the SPE, unfortunately our 510E EVM boards SMI interface is giving me mixed results when reading registers so i cannot trust the integrity or that they working as expected.

    We will need a little time, as I'll be engaging with our firmware team to read Register 0x15 and send results to UART via our products SMI interface. Hopefully get some time next week to come back and let you know on the RX Error Counter.

    Kind regards,

    Daniel

  • 0 in reply to Daniel Haddad
    TI__Mastermind 26772 points

    Hi Daniel,

    Please also read register 0x130 which will check for CRC errors. 

    If we determine there are packet errors, there may be some schematic/layout issue we can look for. 

    Do you have our EVM already? This would be a good way to do a comparison to see if there are any design issues.

    https://www.ti.com/tool/DP83TD510E-EVM

    Thanks,

    David

  • 0 in reply to David Creger
    Intellectual 255 points

    Hi David,

    Apologies for the delay, we have the 510E EVM working that allows us to read the standard and extended registers.

    Although unfortunately there wasn't much latency this time around (strange) only +/- 1-2ms (same setup as above with SPE).

    Both register readings below.. Also for 0x15 i read both the 510e and 822i with readback of 0000 for both PHY's which is great.

    Happy to close this ticket for now, if we encounter this issue again we might need to repeat the process as suggested on this thread and hopefully we can catch something.

    Thanks again for your support.

    Regards,

    Daniel

  • 0 in reply to Daniel Haddad
    TI__Mastermind 26772 points

    Hi Daniel,

    Glad you are able to resolve the issue for now. I will close this thread, please open a new one and reference this thread if some issue arises in the future.

    Thanks,

    David