CPU load: where is the limit?

I use Mr. R. Krten’s “sysmon” http://ftp.parse.com/pub/sysmon/
sysmon-latest-src.tar.gz utility to gauge the CPU load.

Quite often I see the dropping down to ~20% while the most CPU-hog
process consumes ~60% in my particular environment.
Is there any threshold I should watch for with loading a box with the
tasks?

Tony.

“Tony” <mts.spb.suxx@mail.ru> wrote in message
news:opshcwgtago93ri4@mobile.wst.quantum.ru

I use Mr. R. Krten’s “sysmon” > http://ftp.parse.com/pub/sysmon/
sysmon-latest-src.tar.gz utility to gauge the CPU load.

Quite often I see the dropping down to ~20% while the most CPU-hog
process consumes ~60% in my particular environment.

Is there any threshold I should watch for with loading a box with the
tasks?

Well nothing bad is going to happen if the CPU is busy 100% :wink: It’s more
about process priority then CPU usage. If your goal is to be able to enter
command in shell (which by default is priority 10), then you have to make
sure no process higher then priority 10 consume 100% of the CPU. Process of
lower priority you don’t need to be concern about since they will be
preempted by the shell.

For example on my windows box I use “folding at home” which consumes 100%
of CPU, yet I don’t “feel” any drop in performance since it’s a very low
priority task. Would that process run at high priority it would essential
render my PC totaly irresponsive.

Does that answer your question?

Tony.

On Fri, 12 Nov 2004 11:59:47 -0500, Mario Charest
<nowheretobefound@8thdimension.com> wrote:

Well nothing bad is going to happen if the CPU is busy 100% > :wink: > It’s
more about process priority than CPU usage.
…snip…
Does that answer your question?
Yes.

My question was induced by “Net.ether509 and dhcp.client” trouble I had
recently. There I saw my hardware’s IRQ being dropped or not serviced in
time…

May I think that as long the has at least ~10% of CPU - I’m safe no
matter the priority of the CPU-hog process?
Or, this does not warrant that IRQs will be serviced in time, if reaction
should follow not on the next timeslice but in, say, lower tens of
mircoseconds? I’ve seen Proc32 consuming ~90% of CPU…

What is the “worst case” figure for CPU being busy with priority 30 and
still serving IRQs fast?

Tony.

“Tony” <mts.spb.suxx@mail.ru> wrote in message
news:opshc4q5dlo93ri4@mobile.wst.quantum.ru

On Fri, 12 Nov 2004 11:59:47 -0500, Mario Charest
nowheretobefound@8thdimension.com> > wrote:

Well nothing bad is going to happen if the CPU is busy 100% > :wink: > It’s
more about process priority than CPU usage.
…snip…
Does that answer your question?

Yes.

My question was induced by “Net.ether509 and dhcp.client” trouble I had
recently. There I saw my hardware’s IRQ being dropped or not serviced in
time…

How did you come to the conclusion your IRQ were dropped. There is a
difference between an IRQ being dropped and the process not being able to
service a proxy sent by the IRQ.

The only thing that can cause IRQ being dropped is interrupt being disabled
and
IRQ of higher priority lasting too long. This is NOT directly connected to
CPU usage.

In fact CPU usage as reported by sac or sysmon, does not take account time
spent in interrupt.

May I think that as long the has at least ~10% of CPU - I’m safe no
matter the priority of the CPU-hog process?

Again it depends on your definition of safe. You can’t say “no matter the
priority” because
that is exactly what matters.

Or, this does not warrant that IRQs will be serviced in time, if reaction
should follow not on the next timeslice but in, say, lower tens of
mircoseconds? I’ve seen Proc32 consuming ~90% of CPU…

Proc32 on it’s own doesn’t consume CPU (aside for timer management), it
always perform a tasks upon request.

What is the “worst case” figure for CPU being busy with priority 30 and
still serving IRQs fast?

I don’t think that is a number you can predict. It depends on what the
process at priority 30 does (that includes the kernel),
if it doesn’t disable interrupt then ISR will be services. IRQ are higher
priority then software priority.

Plus you can’t talk about percentage, because CPU speed is important. 10% of
2GIG cpu is not the same as 10% of a 66Mzh :wink:

The 66Mzh cpu may need 70% of it’s cpu to handle interrupts (ISR itself and
work done by process) while a 2Gig may only need 1%.

Tony.

On Fri, 12 Nov 2004 16:00:27 -0500, Mario Charest
<nowheretobefound@8thdimension.com> wrote:

How did you come to the conclusion your IRQ were dropped. There is a
difference between an IRQ being dropped and the process not being able
to service a proxy sent by the IRQ.
Thank you for pointing me to that.

I saw my hardware failing during the high CPU load and since the hardware
is IRQ driven - I thought…

May I think that as long the has at least ~10% of CPU - I’m safe
no matter the priority of the CPU-hog process?
Again it depends on your definition of safe. You can’t say “no matter
the priority” because that is exactly what matters.
Well, the name hints on the picture like CPU has done everything

and now it sips beer enjoying the breeze from the fan… :slight_smile:
I thought - if has non-nill CPU usage - the box works as expected…
Don’t you mean that even with of, say, 60% - one may experience the
proxies not being consumed in time?!

Plus you can’t talk about percentage, because CPU speed is important.
10% of 2GHz cpu is not the same as 10% of a 66Mzh > :wink:
:slight_smile:

Yes, I got it now.

Tony.

“Tony” <mts.spb.suxx@mail.ru> wrote in message
news:opshd8kjseo93ri4@mobile…

On Fri, 12 Nov 2004 16:00:27 -0500, Mario Charest
nowheretobefound@8thdimension.com> > wrote:



Don’t you mean that even with of, say, 60% - one may experience the
proxies not being consumed in time?!

Yes that’s possible, but very unlikely since it would only occurs with
program that
aren’t design properly. Imagine a proxy being fired every 10ms in the
following program:

for(;:wink: {
pid = Receive(…);
if ( pid == everyseconds {
do_some_stuff();
delay( 20 );
}
else if ( pid == every10ms ) {
do_some_other_stuff();
}

The delay 20 means every seconds, there will be one, possiblity 2 proxies
queued (not lost), Looking at a program list this through sac, if
do_some_other_stuff() lasts 5 ms, will show you idle at 50%, yet the process
is not able to keep up with proxies all the time.


Plus you can’t talk about percentage, because CPU speed is important.
10% of 2GHz cpu is not the same as 10% of a 66Mzh > :wink:
:slight_smile:
Yes, I got it now.

Tony.