CPU util measurement?
David T. Chen
how does vxworks calculate the CPU utilization? Is it like
the BSD 'uptime' command which gives the average CPU
run queue length for the past 1, 5, and 10 minutes? Thanks
for any short information.
Leonid Rosenboim
VxWorks does not have any permanent mechanism to measure system
load or utilization like "uptime" on Unix. There is only "spy()" which
is implemented in two different versions (one is Tornado based, the
other
is target-resident), reports much more then just utilization.
Spy() statistically collects CPU state and reports relative CPU usage
by each of the active tasks, special kernek and interrupt state, and of
course the Idle state too. Accuracy depends on the frequency of the
timer
used to collect the data, which also has overhead of its own.
Spy() needs a second timer to be available and supported, meaning
sometimes you can not use it.
Of course there is also WindView, which is certainly more ten you have
asked for.
Hope this helps,
Leonid
Bruce
Leonid Rosenboim <leo...@bitband.com> wrote:
>VxWorks does not have any permanent mechanism to measure system
>load or utilization like "uptime" on Unix. There is only "spy()" which
>is implemented in two different versions (one is Tornado based, the
>other
>is target-resident), reports much more then just utilization.
>
>Spy() statistically collects CPU state and reports relative CPU usage
>by each of the active tasks, special kernek and interrupt state, and of
>course the Idle state too. Accuracy depends on the frequency of the
>timer
>used to collect the data, which also has overhead of its own.
>
>Spy() needs a second timer to be available and supported, meaning
>sometimes you can not use it.
>
>Of course there is also WindView, which is certainly more ten you have
>asked for.
If you need something like this, it is trivial to create a task with a
priority of one greater than the idle task and put a counter in it.
Bruce in Katy Texas
Leonid Rosenboim
[snip]
>
> If you need something like this, it is trivial to create a task with a
> priority of one greater than the idle task and put a counter in it.
>
> Bruce in Katy Texas
Bruce, VxWorks does not have an IDLE task! Instead it has got a special
kernel state for "Idle" so that when the first task becomes ready,
it only has to do "half" a context switch.
Still, to measure CPU utilization is possible with a task at the lowest
priority 255, which needs to first calibrate itself to measure
how fast is the CPU and then measure and report it's relative speed
and thus availability. I have done this several times, and it is not
trivial at times, because of all those caches changing the CPU
performance
in the most peculiar ways.
Take care,
Leonid
Ted Dennison
leo...@bitband.com wrote:
> Still, to measure CPU utilization is possible with a task at the
> lowest priority 255, which needs to first calibrate itself to measure
> how fast is the CPU and then measure and report it's relative speed
> and thus availability. I have done this several times, and it is not
> trivial at times, because of all those caches changing the CPU
Often times what you really need to do is show that CPU utilization
never drops below a certian percentage, without having to go through the
rigor of a formal proof. What we do is write a cpu-eater task that gets
called at the highest rate and does not relinquish the CPU until after a
set percentage (say half) of the frequency has passed. If we can process
normally with no reported frame-overruns from the other tasks, then we
have shown that we have at least %50 CPU time free.
--
T.E.D.
http://www.telepath.com/~dennison/Ted/TED.html
Sent via Deja.com http://www.deja.com/
Before you buy.
Bill Beckwith
<85ibpt$8ao$1...@nnrp1.deja.com>:
>
>Often times what you really need to do is show that CPU utilization
>never drops below a certian percentage, without having to go through the
>rigor of a formal proof. What we do is write a cpu-eater task that gets
>called at the highest rate and does not relinquish the CPU until after a
>set percentage (say half) of the frequency has passed. If we can process
>normally with no reported frame-overruns from the other tasks, then we
>have shown that we have at least %50 CPU time free.
"called at the highest rate" would have to be the highest
priority hardware interrupt since a task at the highest
software priority couldn't guarantee that it was actually
getting half of the CPU time (since all hardware interrupts
would take precidence).
-- Bill
Bill Beckwith
<8ECBDE36Abe...@sigma.ois.com>:
I spoke too soon.
The task at the highest software priority could
turn off interrupts while it is eating CPU. :-)
-- Bill