This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

CPU utilization measurment failure

Hello,
I am working on a STR9 scheduler (it is open source - will post a link here when it is ready on the condition you help me to solve this problem :-) )
I don't understand why my code to measure the CPU utilization does not work. It is very simply really: I have an idle task that counts as fast as possible (with the scheduler disabled) upon startup for one second. It saves the accumulated value, then the scheduler is re-enabled and the count begins again, evaluated every second. The ratio between the initial accumulated value and the once per second generated count is the CPU utilization - but the amazing thing is that the one per second count, with the scheduler enabled, tends to the bigger than the initial count (with the scheduler disabled) !
I am quite sure there is no overflow involved - it goes wrong even if I make a measurement every 300 milliseconds (as demonstrated below). Any ideas/recommendations?

// idle task. always executed, and scheduled first
static void idle_task(void)
{
        int32u  l_scheduler_state ;
        int32u  l_counter = 0 ;

        scheduler_disable(&l_scheduler_state) ;

        while (1)
        {
                ++l_counter ; // it is faster to count into a register-allocated variable

                // and later assigned the accumulated value into a static

                if (timer_poll(IDLE_TASK_TIMER, MILLISECONDS_X_10(30), 0) )
                {
                        s_performance_counter_init = l_counter ;
                        l_counter = 0 ;

                        break ;
                }
        }

        scheduler_restore(l_scheduler_state) ;

        while (1)
        {
                ++l_counter ;

                if (timer_poll(IDLE_TASK_TIMER, MILLISECONDS_X_10(30), 0) )
                {
                        s_cpu_utilization = 100 - ( (l_counter * 100) / s_performance_counter_init) ;
                        l_counter = 0 ;

                        debug_message("cpu load %d%\n", s_cpu_utilization) ;
                }
        }
}

  • Have you looked at the assembler to see if there is any optimization that might be affecting it?

    Would it be worth putting your two blocks of loop code into a single shared function - To ensure that exactly the same code is executed on each of the two attempts?

  • Hi Tamir,

    is it possible that your 'timer_poll' function doesn't provide the functionality you expect?

    Frank

  • Arthur, F D,
    Thanks for your replies. I know what's wrong: the answer is in the function's name! Having several task execute instruction causes a jitter in the exact moment the value of the hardware timer is evaluated. I wanted to reduce interrupt latency by removing some functionality to program context but that is not functioning as expected and will not generate predictable delays which is unacceptable. I will fix it, but try to make it fit elegantly. You will get to see the result (hopefully, soon...)