• State
  • Replies 9 replies
  • Subscribers 31 subscribers
  • Views 82 views
  • Users 0 members are here
Support feedback
Options
Options
Related

Original question:

AM2431: AM243x CPTS module and Time Sync Router Questions

AM2434: CPSW/EST Quantisation-Granularity on TI Sitara AM243x

Florian Ertl
Prodigy 50 points

Part Number: AM2434

Hello,

i've built an application based on the gPTP/EST-Example. One Ethernet-Frame is created every 250 µs through a triggered interupt using the GENF-Module. Afterwards, it's released using the EST-Mechanism on a seperate queue (Nothing else is there allowed and im using a Guardband to protect the slot, additionaly between creating the frame and queuing it enough time should pass).

Now i can view on my reciever a NIC i210 that the differences between arrival times of 2 frames is not really constant. It jumps between 250.113 µs and 249.857 µs (256 µs difference) but it seems kind of random. Can you explain this behaviour? Has it something to do how frames are fetched for/from the EST queues?

inter_arrival_time_between_pakets.png

The y-axis is the arrival time difference, the x-axis the paket-number. 
The raw mean is mean of all paket arrival differences. Here are a few burst events included, because the gPTP-Task delayed the Frame-Creation-Task although gPTP has the lower priority configured. 
The filtered mean is the mean of the paket arrival differences shown in this image.

Best regards,

Flo

  • 0
    TI__Genius 9520 points

    Hi Flo,

    Although the i210 card and the DUT (AM243x) are in time sync, if we are observing such difference, then it would indicate probable accuracy loss between the boards, and could be verified with the default prints available in the application or through an oscilloscope.

    We have observed cases where the accuracy on the boards is in 1-2 us range in some board revisions where the clock circuitry is causing these issues.

    I will try to reproduce this issue sometime next week and will update you the results and findings. Please expect a response in 5-6 business days.

    Thanks and regards,
    Teja.

  • 0 in reply to Teja Rowthu
    Prodigy 50 points

    Hi Teja,

    i don't think it's accuracy loss. Parallel i've probed my setup and i measured rms-jitter of 5 ns between the LP Genf signal and the NIC. The maximum Peak-to-Peak jitter in 30 Minutes was only 30 ns.

    Best regards

    Flo

  • 0 in reply to Florian Ertl
    TI__Genius 9520 points

    Hi Flo,

    If the jitter is within 5ns, then this rules out the accuracy issues. Please let us look into this issue and check for possible causes for this inconsistency in the EST window times. Please expect a response in 2 days.

    Thanks and regards,
    Teja.

  • 0 in reply to Teja Rowthu
    Prodigy 50 points

    Hi Teja, 

    did you have any Luck? Any Results yet available?

    Best Regards,

    Flo

  • 0 in reply to Florian Ertl
    TI__Genius 9520 points

    Hi Flo,

    Due to other high priority schedule, I was not able to test this last week. I will schedule this early this week, and will update you by wednesday.

    Thank you for your patience,

    Best regards,
    Teja.

  • 0 in reply to Teja Rowthu
    Prodigy 50 points

    Hi Teja,

    did you find the time?

    Best regards,

    Flo

  • 0 in reply to Florian Ertl
    TI__Genius 9520 points

    Hi Flo,

    For a 64 Byte packet size, the acceptable window size is close to 0.8-1 usec. The observed variance is close to 0.1-0.15 usec, which is within the expectation of the spec, and suggested limits. Does your applicaiton need even tighter tolerances for the packet sending?

    If yes, please let us know some more details on the usecase so that we would be able to help you identify the available options.

    Thanks and regards,
    Teja.

  • 0 in reply to Teja Rowthu
    Prodigy 50 points

    Hi Teja,

    the variance is 127 ns, peak to peak is 256 ns. I think it has something to do with how data is fetched from the  EST-queues and maybe some clock domain crossing at this point. 

    I am trying to implement highly deterministic TSN-Communication, ideally with RMS-jitter < 10 ns. My gPTP - synchronized network currently reaches this level of jitter, but as you see, the transmission of the pakets doesn't operate at the same level.
    The overall goal is to determine, what the capabilities of TSN and currently available TSN-Hardware are.

    Because the jitter is discrete and jumps only between 2 levels, i would have thought, that maybe with the right configurations one can loose this current behaviour?

    Best regards,
    Flo




  • 0 in reply to Florian Ertl
    TI__Genius 9520 points

    Hi Flo,

    Thank you for explaining your usecase. I am discussing with our development team on more details regarding the EST fetch behaviour. I will keep you posted on the findings

    Thanks and regards,
    Teja.