> Hello,
> 
> is there a way to get accurate information of the free cpu time (= the idle 
> time of a core)? 
> 
> My problem is the resolution of the qnx accounting. Using clock_gettime() or 
> devctl(..., DCMD_PROC_INFO, ) information, one get's very vague values. 
> 
> For example a process is triggered by an interrupt and is running with a 
> period of 1ms + the system's period is 1ms, the process is running for 500us /
>  cycle. This would be around 50% load on one core. But the /proc/<pid>/as 
> information is wrong.
> 
> As far as I know, this is because the cpu usage is updated with each system 
> tick and thus has a resolution of 1ms. This leads to an enormous error in case
>  some processes are running periodically with a period >= the system clock...
> 
> I tried using itel's APERF/MPERF using rdmsr, which works pretty well. But it 
> needs to executed in priviledge level 0, so I used an isr, but all isr are 
> running on core0 -> no way for me to get the information of core1 ... coreN
> 
> 
> Any Ideas? 
> 
> Thanks!
> Matthias
> 
Scheduler and time accounting - an endless riddle ...
Take a look at the sched and you'll see that it uses not just a time value, but also some micro billing on kernel calls 
for your thread.
If you don't want to rely on hw specific things, you can use "Dynamic Event Filtering" from the TraceEvent() API.
You can use this without having tracelogger active.
Your app will have to look for RUNNING Events from each idle thread and has to check for the next 'other' RUNNING for 
each core.
You'll have to fiddle with TraceEvent callback data, and you also you hace to take care about Interrupt Events (the 
active process does not get a state change on an interrupt).
Other solutions will require HW related implementations.
This is the most accurate accounting with lowest possoible runtime impact I know - without using HW specifics.

I did this in the past - but I can't share the source.

HTH
/hp