• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 100 subscribers
  • Views 380 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.

sysbios performance

Weichun Yuan
Expert 1210 points
Other Parts Discussed in Thread: SYSBIOS

We are planning to run sysBios (6.32.05.54) on C6657 based VoIP application. We plan to port the linux based system to sysBios. We will have hundreds of semaphors, most of them will be given and posted every 10ms, and dozens of sysBios tasks and sysBiosMailboxes.

Do we expect performance issue or other problems in such a system? Is there anything we have to pay attention to?

thanks

Weichun

  • 0
    TI__Mastermind 21645 points

    Hi Yuan,

    I don't believe you should have any performance issues with BIOS. SYS/BIOS has been used in many other systems with complexity similar to what you describe for your system, without any issues. It would be a good idea to go through the SYS/BIOS user guide and understand the various APIs/features before you start. You can also look at the SYS/BIOS benchmarks to help you design/implement your application.

    Is there any particular reason for using SYS/BIOS release 6.32.05.54 ? There are newer SYS/BIOS releases (6.35.01.29 is latest) which you can use.

    Best,

    Ashish

  • 0
    TI__Mastermind 18320 points

    I largely agree with Ashish.  But you should definitely pay close attention to your system design as you implement this large kind of system -- in particular to memory constraints and to latency.

    The memory overhead of a task is related to its stack.  You will need to make sure that system memory is large enough to accommodate the creation of the number of tasks that you envision.  You will also probably need to tune the individual stack sizes so that they are not unnecessarily large (i.e., significantly bigger than the task will ever actually use), but not too small as to cause a stack overrun under particular conditions.  The latter can be difficult to analyze, as maximum stack usage may only occur under a very narrow set of system scenarios, and you may have to do some extensive and extended real time analysis  to make sure you have this right.  You can also look further into the SYS/BIOS Software Interrupt mechanism as a potential alternative way to implement a thread that does not require a separate stack.  You may also be able to optimize task memory usage by creating tasks statically via the SYS/BIOS configuration tool rather than at run-time.  You should also look at your memory allocation policies and optimum heap memory manager.

    With more complex systems, you should also look at how often task context switches occur and make sure that the context switch overhead is not taking up an unreasonable percentage of your CPU cycles, either because of high interrupt rates, or because of a large number of different semaphores being posted in a short period of time.  Software Interrupt threads can often help with this aspect as well as they can be set up to to be posted multiple times but only run once.  For higher rate interrupts, you may also need to implement some special strategies such as only forcing context switches after a number of interrupts occur rather than on each one.

    The SYS/BIOS ROV and RTA tools can help you analyze and optimize your software implementation with regard to how it utilizes the SYS/BIOS kernel, so you should definitely familiarize yourself with that.

    All of the different tools and features that I described above are well described in the SYS/BIOS User Guide (SPRUEX3L), so if you haven't done so already, you should familiarize yourself with that.  And of course, you can always post more questions that you have in this forum.

    Good Luck!

    Dave

  • 0 in reply to David Friedland
    Expert 1505 points

    Hi David

     

    Really enjoyed your videos. was not aware "YOu may also be able to optimize task memory usage by creating tasks statically via the SYS/BIOS configuration tool rather than at run-time"

    How does that MEMORY saving work?

  • 0 in reply to Mark Lazarewicz
    TI__Mastermind 18320 points

    Static creation of tasks should save memory usage for the simple reason that you will not need to code in your application for creating (and deleting) the tasks during run time.  And if all of your system object creation is done statically, your application will also not need a memory manager as well.  Static creation means that all of your system objects (e.g, tasks, semaphores, etc) will be created during build time rather than run time.  Some applications really do need or want run-time objection creation and deletion, so SYS/BIOS has capabilities for both paradigms.