[ECOS] Regd CPU IDLE TIME calculation.

Andrew Lunn andrew.lunn@ascom.ch
Wed Mar 26 09:59:00 GMT 2003


On Wed, Mar 26, 2003 at 09:14:56AM +0000, Prabal Halder wrote:
> 
> 
> Sir,
> 
>      We are using eCos1.3.1 for our project.

This is very old and not recommended.

 But we
> are having problem while calculatiing the CPU IDLE
> time.

I don't see how the CPU idle time is related to what you are
describing below. Could you explain this a bit more. What are you
trying to achieve?
 
>    I am describing the problem.
> 
> System parameters are :
> CYGNUM_KERNEL_COUNTERS_RTC_PERIOD = 31250
> CYGNUM_HAL_RTC_PERIOD = 31250
> CYGNUM_HAL_RTC_DENOMINATOR = 100
> 
>   Here we are proceding as follows.
>   
>                 One of our application threads is
> system_performance thread( say SYS_PERFORM_THREAD).
> The executing function of this thread is
> 
> void func()
> {
>  while(1)
>  {
>     cyg_thread_delay(1000);  // delay for 1000 tick.
>     print the value of the total number of context    
>      switches since the last execution of this 
>     thread.
>  }
> } /* void func()*/
>  
>   That is,
> 
>     The SYS_PERFORM_THREAD thread only wakes up after
> every 1000 tick and prints the value of the number of
> context switches in system since the time this thread
> last executed. The number of context switches is
> calculated and saved by kernel in "thread_switches"
> variable in scheduler class. We are using mlqueue
> scheduler.
>    The result we got :
> 
> Number of context switches : 174
> 
> Number of context switches : 156
> 
> Number of context switches : 155
> 
> Number of context switches : 156
> 
> Number of context switches : 163
> 
> Number of context switches : 166
> 
>     
>     
>     My questions are :
> 
> 1. How many real time clock ticks ( 1 tick = 10msec) a
>     thread gets in each time quantum?

The round robin time is controlled by
CYGNUM_KERNEL_SCHED_TIMESLICE_TICKS. This defaults to 5 ticks. So,
where there are multiple threads which have the same priority and are
runable, every 5 ticks a context switch will happen.

> 2. If in each time quantum is equal to 1 tick, then
> why    the number of context switches is so low and
> where     the remaining time is elapsed?

1000/5 = 200. So you are still around 40 short. What exactly does this
counter count? Look at the code. Maybe it counts actual context
switches, not potential context switches. ie if there is not another
thread at the same priority which is runnable at the end of the time
quanta, it won't context switch since there is nothing to switch
to. Also, if you have the network stack running, that maybe causing
context switches when its timers go off. Are you really sure the
system is idle and there are no other threads? 
 
> 3. Here the hardware clock tick value is 31250 after  
>     which timer interrupt occurs. This 31250 hareware 
>  
>    tick is equal to how many tick? ( 1 tick = 10msec)?

The hardware by default should be interrupting every 10ms. So, 31250
is probably 10ms.

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss



More information about the Ecos-discuss mailing list