• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 793 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.

Tick timer effect on IPC Message Q latency

Dominick Trascritti
Prodigy 55 points

I am collaborating with a colleague using TI BIOS on IPC section, and I am concerned about the IPC latency and tick timer. We are using IPC MessageQ for signaling a calculation is finished by Core3 and ready to be read from shared memory by Core0 (for example).

What is concerning is this: "IPC applications are configured to use the ti.sdo.ipc.notifyDrivers.NotifyDriverShm Notify driver and the ti.sdo.ipc.transports.TransportShm MessageQ transport."

This makes us worry about the tick timer and the impact on an IPC MessageQ object. We would rather use the MessageQ and not roll our own, but we have to meet timing.

QUESTION: Please confirm that when I send a message, the tick timer value has no impact on the time to notify one core to another?
QUESTION: Using the synchronizer, are we independent of the tick timer latency value?

For reference a related post about changing tick timer to 20ms:

e2e.ti.com/.../1714451

  • 0
    TI__Mastermind 18260 points

    Dominick Trascritti said:
    QUESTION: Please confirm that when I send a message, the tick timer value has no impact on the time to notify one core to another?

    There will be no direct impact on MessageQ message delivery when you change the Clock's tick period.

    The only impact would be to overall CPU load - decreasing the tick period would cause more tick interrupt firing/processing, but that is a minimal impact on CPU load anyways.

    And since MessageQ_get() has a timeout parameter, changing the tick period would affect the wakeup latency of the code calling MessageQ_get() *only* when the timeout expires, but that is in play only when the message doesn't get delivered for whatever reason.

    Dominick Trascritti said:
    QUESTION: Using the synchronizer, are we independent of the tick timer latency value?

    What do you mean by "Using the synchronizer"?

    Regards,

    - Rob

  • 0 in reply to Robert Tivy
    Prodigy 55 points
    I am referring to "The Inter-Processor Communication Package" SPRUGO6E page 26.

    "For example, if the reader is a SYS/BIOS Swi, the instance could be a SyncSwi. When a MessageQ_put()
    is called, the Swi_post() API would be called. The Swi would run and it must call MessageQ_get() until
    no messages are returned. If the Swi does not get all the messages, the Swi will not run again, or at least
    will not run until a new message is placed on the queue."

    It sounds like a SWI, which made me worry about tick count.

    There are a few options, I think your answer took me 90% there though.
  • 0 in reply to Dominick Trascritti
    TI__Mastermind 18260 points

    Dominick Trascritti said:
    It sounds like a SWI, which made me worry about tick count

    The only things in SYS/BIOS that operate based on the Clock tick are Task_sleep()s and timeouts for blocking functions (such as MessageQ_get()).  Everything else operates in a straight code-flow fashion.  Any tick latency affects *only* the sleep or timeout wakeup time.  As far as delivering a MessageQ message, the SYS/BIOS tick does not even come into play (except as far as the time it takes to run the tick processing ISR).  There is no scheduling done based on the SYS/BIOS tick, all scheduling is "event" based.

    You could easily have an IPC application that doesn't even have a SYS/BIOS tick, and the only functionality that would be missing are the time-based timeouts (and I'm considering Task_sleep() to be a timeout for the sake of this discussion).  With no tick, as long as you specified timeouts as either 0 (poll-based) or BIOS_WAIT_FOREVER, things would work normally.

    Regards,

    - Rob