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

Sensitivity of MBX timing benchmarks to message length

Oliver Francis
Prodigy 60 points

Hi guys,

I wonder if you can help me.  Did the DSP/BIOS developers perform an analysis of the execution times of the MBX calls with different message lengths?  The MBX benchmarks in the results.htm file only use a message length of one MADU, which is of limited usefulness beyond defining a "best case". 

I imagine that the execution times have two main components:

- Fixed costs (DSP/BIOS overhead, which will depend on whether or not a task is waiting and can be run); and

- Variable costs (due to the size of the message length in MADUs)

In particular, I am interested in the relative importance of each kind of cost.  For example, if a MBX is called with a message length of one, how how will the timing increase if the message length were changed to 256?  Would it double? Triple?  Are the timings in results.htm comprised of 90% execution time due to the fixed cost and 10% due to the variable?

Kind regards,

Oliver

  • 0
    TI__Mastermind 30830 points

    Oliver,

    The benchmarks are provided to show minimum times so the user knows how much fixed overhead there is.

    Internally, MBX uses 'memcpy()' to do the data copy so the performance degradation as the message size goes up is due entirely to the performance of 'memcpy()'.

    The amount of time memcpy() takes will depend on the message size as well as the access times for the 'to' and 'from' buffer memories.

    Alan

  • 0 in reply to Alan DeMars
    Prodigy 60 points

    Hi Alan,

    Thanks for getting back to me.  That's certainly food for thought.  Our C standard library .text is loaded into off-chip, single-cycle wait-state SD RAM, but our buffer memories are in on-chip zero wait-state RAM.  Experimentation is required on our behalf to work out our worst-case times, but it would have been useful to have a few other ballpark figures to give us an idea.

    Once again, thanks for getting back to me.

    Kind regards,

    Oliver