I have found some sample code in the Tornado FAQs to find out the CPU usage.
CPUIdleMonitor.c (for example). The method is the burn the CPU with a low priority task, and find how long that low priority task consumed the CPU. The CPU usage by others will be (100-The time taken by this task).
Do you think I can run this program in a system which runs for days and months to find out the CPU usage ? I found this is as good as we are consuming the CPU 100 % every time and heating the CPU. Operating systems like Windows, Linux etc will run Idle Process, which is a cooling process or book keeping process which does nothing to CPU. These Idle process doesnot consume CPU. The process/task scheduler can calculate how long time the Idle process/task was running and find the CPU usage for the other tasks.
An Idle process running means he does book keeping and cools down the CPU. (Bascially does nothing)
Is it recomended to use this implementation in real time systems which running for days and months with out rebooting ? Doesnt this heat up CPU. ? Does any one uses this in the system. ?
Does any one suggest any other method for calculating CPU usage time. ?
Please let me know your views
Thanks
Regards
Kiran
days, months, should not be a problem.
> I found this is as good as we are
> consuming the CPU 100 % every time and heating the CPU.
> Operating
> systems like Windows, Linux etc will run Idle Process, which is a
> cooling process or book keeping process which does nothing to CPU. These
> Idle process doesnot consume CPU.
I believe your assumptions are incorrect. If you are "book keeping"
or "idle", the processor still needs to run some instruction at the
fixed processor rate. Windows or Linux may have drivers for your
hardware that enable hardware power saving modes like lowering the
processor clock rate, or putting certain chips/devices to sleep.
> The process/task scheduler can
> calculate how long time the Idle process/task was running and find the
> CPU usage for the other tasks.
Only if it has a separate clock/timer chip and a method to awake up
the processor.
> An Idle process running means he does book keeping and cools down the
> CPU. (Bascially does nothing)
An idle process could run entirely within a single chip and therefore
shutdown RAM, FPU, and other devices that are not used to wake up the
system later.
Don't know what you mean by book keeping, but if you mean garbage
collection , then you are probably involving RAM and the ALU, so I am
not sure there is any power saving in the processor.
> Is it recomended to use this implementation in real time systems which
> running for days and months with out rebooting ? Doesnt this heat up
> CPU. ? Does any one uses this in the system. ?
You need to look at you power and heat requirements/constaints. There
are many embedded systems that are up 24h/7d. If the CPU is powered
up it will do WORK; no CPU is 100% efficient so there will be loss in
the form of heat... Its just like gravity; a constant.
--Eddie Sanchez
This is not really quite correct. Many processor have a specific sleep type
instruction that once executed
halts most of the processor until some interrupt occurs (be it external or
perhaps the OS task scheduler interrupt).
For example, on MIPS this instruction is WAIT. Some OSs (and certainly older
versions of vxWorks) never make
use of this instruction during "idle" periods and they simply go into a busy
wait loop. I don't know if newer vxWorks
OSs support optionally having the busy wait execute a sleep type
instruction.
I dont see any reason why one could not have their own home grown idle task
that simply loops
on a sleep type instruction. Some levels of sleep instructions do incurr a
latency as the processor
exits sleep so you'd have to look to see what you want.
> > Operating
> > systems like Windows, Linux etc will run Idle Process, which is a
> > cooling process or book keeping process which does nothing to CPU. These
> > Idle process doesnot consume CPU.
> I believe your assumptions are incorrect. If you are "book keeping"
> or "idle", the processor still needs to run some instruction at the
> fixed processor rate. Windows or Linux may have drivers for your
> hardware that enable hardware power saving modes like lowering the
> processor clock rate, or putting certain chips/devices to sleep.
Well, both of you are right! In VxWorks, the idle loop is usually just
that - a busy loop:
idle:
goto idle;
There are some chips (most notably x86 family) that have a simple
power saving mode that can be used in the idle loop to sleep the
processor until the next interrupt. It has some power saving
advantages, even in a system where there is a regular clock interrupt,
but it also has an impact on interrupt latency. Waking up, even from
this very shallow sleep state, does take a little bit of extra time.
Other architectures had hook functions in the scheduler that could be
used to reduce the power in the idle state, but to be honest I would
recommend doing that in a low priority task as well (just make sure
you don't prevent the clock interrupt from getting through - the OS
will not work as well if that is blocked during the low power states).
> > An Idle process running means he does book keeping and cools down the
> > CPU. (Bascially does nothing)
> An idle process could run entirely within a single chip and therefore
> shutdown RAM, FPU, and other devices that are not used to wake up the
> system later.
Apart from the special sleep instruction for x86 (which I don't think
was used in any version of VxWorks that shipped - we were playing with
it internally to see whether it was useful though), VxWorks doesn't
shut down anything in the idle state by default. Of course, since the
loop is in cache the RAM won't actually be accessed which will save
power there. It makes no difference though if this code is in the
scheduler routine or if it is in your idle task - the CPU will do the
same things once in the loop.
> > Is it recomended to use this implementation in real time systems which
> > running for days and months with out rebooting ? Doesnt this heat up
> > CPU. ? Does any one uses this in the system. ?
> You need to look at you power and heat requirements/constaints. There
> are many embedded systems that are up 24h/7d. If the CPU is powered
> up it will do WORK; no CPU is 100% efficient so there will be loss in
> the form of heat... Its just like gravity; a constant.
Well, no, not really. It is not a constant. As with most things, it is
changes in state that require work and therefore generate heat.
Obviously, the clock and things connected to it are changing all the
time (unless the CPU is put into a sleep state), so that will be
roughly constant. The registers, ALU, cache, memory management unit
etc will not be used as heavily in an idle loop though, so there is a
reduction in the heat generated there.
Of course, if your system cannot dissipate the maximum heat that the
CPU can generate then I would suggest that you need to rethink the h/w
design. The heat dissipation requirements of CPUs (and other "hot"
components like the RAM) as well as their maximum operating
temperature is well documented; any hardware design should take these
numbers into account and ensure adequate cooling is available. Some
CPUs even include thermal protection systems that will shut them down
if they get too hot.
For what was proposed though, since the idle task & OS idle loop are
essentially the same from the CPU's perspective, I wouldn't worry
about it unless you believe the h/w cannot handle its max heat
dissipation requirements. You could actually consider it to be a good
burn-in test for the system too, especially if this is a device that
will be on all day every day when deployed.
HTH,
John...
=====
Contribute to the VxWorks Cookbook at: http://books.bluedonkey.org/