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.

100% CPU load with high accuracy on the PRD-Timers.

Hi,

I´m using the C6747 (DSP BIOS 5.33.05, CGT v6.1.10) on an EVM-board and have a question regarding the PRD timer set up in DSP BIOS. The Clock Manager is used to drive the PRD module. The Clock Manager has the following settings:

Object Memory: IRAM, Timer Selection: Timer 0, Use high resolution time for internal timings: Yes, Eneble High Resolution Timer: Yes, Specify input clock rate: Yes (24MHz), Reset Timer and Time mode: Yes (32-bit unchained), Directly configure on-chip timer registers: Yes (PRD Register: 1000).

These settings give me a time resolution of 41.6us which will be good enough for my application but also a CPU load of 100% which is not desirable. If I increase the PRD setting to 10000 instead of 1000 I get a time resolution of 416us and a CPU load of 15%.

It would be nice to be able to use the higher time resolution so the qusteion is if I´m missing something in the set up or do the BIOS actually use all the "CPU-power" for scheduling the higher time resolution?

 

  • Hi Tobias,

    The timer in DSP/BIOS is not only for generating PRD interrupts, but the timer is used by the DSP/BIOS scheduler. So, it is better that your final resolution (in the field Microseconds/Int) be higher than the resolution you will need your program to be interrupted. So if you need to process something every 41.6us, than you would need to run the timer for the DSP/BIOS scheduler faster than that (for example change from 1000 to 100) to make sure you are not overloading the scheduler by running it too slow.

     Than you would have 4.6us/int and you could create a PRD that runs every 10 ticks (one tick would be 4.16us): 

    Despite of the fact the your PRD should run a little slower than the timer, you have to remember that by using a faster timer for DSP/BIOS, you are using more of the CPU. So if your PRD and timer run slower, it will consume less of the CPU and leave you time to do other tasks. If you run it fast, depending on the time you are spending inside the PRD (processing what you need), you might be overloading the CPU and getting to the 100%. The main problem is that you might need to optimize what you are running so it can run in less than 41.6us.

      

     

  • What is it that you're trying to do every 41.6 microseconds?  Perhaps with a higher level understanding of what you're trying to accomplish someone might be able to suggest a better way of doing it.

  • Hi,

    Sorry for the delay....but now I'm back on track with the right e-mail account (I borrowed Tobias:-) )

    This is my intention:

    - I´m using the CLK-module to generate interrupts for "my own" system-time (seconds.slot.counter) where I want to have the accuracy (1/24000 sec) for the counter value. I´m not doing any heavy calculations, the code is just increasing the counter value at every CLK-interrupt and every time the counter reaches 1000 it´s time for a new slot-interrupt (SWI_post(&slot)). That´s all.

    This is the behaviour for a simple test I did (CPU-Load versus PRD-Timer accuray):

    Time_Accuracy us DSP_Load
    PRD: 1000, No of PRD:s: 1000 41,6 100%
    PRD: 1250, No of PRD:s: 800 52 100%
    PRD: 1500, No of PRD:s: 667 62,4 100%
    PRD: 1600, No of PRD:s: 625 66,5 85%
    PRD: 1700, No of PRD:s: 588 70,7 80%
    PRD: 1750, No of PRD:s: 571 72,8 78%
    PRD: 2000, No of PRD:s: 500 83 69%
    PRD: 4000, No of PRD:s: 250 166 36%
    PRD: 6000, No of PRD:s: ~167 250 25%
    PRD: 8000, No of PRD:s: 125 332 19%
    PRD: 10000, No of PRD:s: 100 416 17%
    PRD: 20000, No of PRD:s: 50 832 10%

    Is it something wrong with my DSP/BIOS configuration or is it correct that the DSP-load is i.e 69% for the accuray of 83us for my counter value? It seems to be quite high?

    Regards, Marcus

     

     

  • What are you trying to accomplish?  It would be better to give your table in terms of BIOS configuration settings so we can see exactly what you are doing/changing.

    Keep in mind that whatever time period you setup for the BIOS tick will physically cause a timer interrupt to occur at that period.  In other words, you'll have a complete context switch, BIOS kernel will execute, and then a complete context switch to whatever is deemed highest priority by the kernel.  Generally I recommend keeping this at 1ms.  If you go much faster than 1ms than an inordinate amount of time is spent doing context switches for the kernel.