calculation of cpu idle time

[ram.ragu]

hi
i have problem to calculate idle time of cpu and if idle time is
more then i have to shut down the system. can anyone tell me the idea
to so that please

 

[Ancient_Hacker]

hi
i have problem to calculate idle time of cpu and if idle time is
more then i have to shut down the system. can anyone tell me the idea
to so that please

You mean if the CPU seems to be idle, you shut it down?

Shutting it down isnt something C can do by itself, but if your C has
the "system"
function, or if you can put the command that runs this program in a
batch file, you're okay.

Just do a system( "shutdown") or put "shutdown" in the batch file,
whatever command shuts down your computer.

Now to figure out if it's idle, that's a bit tricky. But doable, if
your C has a function that returns you the current time, preferably in
small increments. The idea is to form a histogram of the intervals
between the values time() returns, something like:

#include <time.h>

#define MaxMsec 1000

unsigned long int Histo[ MaxMsec ];
int i, j; time_t Now, Prev, Elap, Base;
for( i = 0; i < MaxHisto; i++ ) Histo = 0;

Prev = 0; Base = Prev = time();

for( j = 1; j < 100000; j++ ) {
Now = time() - Base; Elap = Now - Prev; Prev = Now;
If( Elap < 0 ) fprintf( stderr, "Time going backwards!!\n" )
else
If( Elap >= MaxMsec ) Elap = MaxMsec;
Histo[ Elap ] ++;
}

.... then scan the histogram. If the CPU is very idle, you should see a
big peak at very low or zero msec. If there are significant other
tasks running, you'll see other peaks, usually in the range of 5 to 50
msec. (Many OS's scheduling algorithms allocate time in slices of 5 to
50 msec).

To be sure, put a loop around that code so it runs for several seconds.

Yes, not guaranteed to work anywhere, but seems to do the job on
Windows and Linux.

 

[Eric Sosman]

Ancient_Hacker wrote On 08/23/06 11:45,:

[...]

Now to figure out if it's idle, that's a bit tricky. But doable, if
your C has a function that returns you the current time, preferably in
small increments. The idea is to form a histogram of the intervals
between the values time() returns, something like:
[the Millikan oil-drop experiment]

This is terrible advice, and badly coded.

 

[Ancient_Hacker]

Ancient_Hacker wrote On 08/23/06 11:45,:

[...]

Now to figure out if it's idle, that's a bit tricky. But doable, if
your C has a function that returns you the current time, preferably in
small increments. The idea is to form a histogram of the intervals
between the values time() returns, something like:
[the Millikan oil-drop experiment]

This is terrible advice, and badly coded.

Thank you so much for your opinion.

Your opinion would have more weight if:

(1) You had a viable alternative.
(2) You explained why this is "badly" coded. I see one goof-- we're
not detecting time going backwards correctly. Otherwise there are darn
few ways to do a simple histogram. Please feel free to educate me.

 

[Eric Sosman]

Ancient_Hacker wrote On 08/23/06 12:47,:

Ancient_Hacker wrote On 08/23/06 11:45,:

[...]

Now to figure out if it's idle, that's a bit tricky. But doable, if
your C has a function that returns you the current time, preferably in
small increments. The idea is to form a histogram of the intervals
between the values time() returns, something like:
[the Millikan oil-drop experiment]

This is terrible advice, and badly coded.

Thank you so much for your opinion.

Your opinion would have more weight if:

(1) You had a viable alternative.
(2) You explained why this is "badly" coded. I see one goof-- we're
not detecting time going backwards correctly. Otherwise there are darn
few ways to do a simple histogram. Please feel free to educate me.

I tried educating you once before (when you were having
trouble understanding arrays), and failed to get the ideas
across. Could be my lack, could be yours -- either way, it
didn't work and became actively unpleasant. I've no desire
to try again.

 

[Ben Pfaff]

Ancient_Hacker wrote On 08/23/06 11:45,:

[...]

Now to figure out if it's idle, that's a bit tricky. But doable, if
your C has a function that returns you the current time, preferably in
small increments. The idea is to form a histogram of the intervals
between the values time() returns, something like:
[the Millikan oil-drop experiment]

This is terrible advice, and badly coded.

Thank you so much for your opinion.

Your opinion would have more weight if:

One reason it is poor advice is that it raises the CPU load
average by 1, for several seconds, just to roughly approximate
the CPU load average. I don't think that's acceptable. It is
kind of amusing, but no one (I hope) would consider doing that
except as a joke.

 

[Ancient_Hacker]

average by 1, for several seconds, just to roughly approximate
the CPU load average. I don't think that's acceptable. It is
kind of amusing, but no one (I hope) would consider doing that
except as a joke.

I didnt want to get into the grungy details, but you're right, the code
can be much improved by doing a SetProcessPriority( LOW ). Then the
code not only soaks up less CPU time, it will more accurately reflect
the effects of other running tasks.

But that of course adding calls to change the CPU priority is even less
portable.

 

[Flash Gordon]

Ancient_Hacker wrote On 08/23/06 11:45,:

[...]

Now to figure out if it's idle, that's a bit tricky. But doable, if
your C has a function that returns you the current time, preferably in
small increments. The idea is to form a histogram of the intervals
between the values time() returns, something like:
[the Millikan oil-drop experiment]

This is terrible advice, and badly coded.

Thank you so much for your opinion.

Your opinion would have more weight if:

(1) You had a viable alternative.

Call whatever routine the OS provides for detecting the amount of idle
time. Most OSes where the concept is useful provide such a routine, how
else do you think the process monitors work?

You are creating a busy loop which is not what is wanted. It will slow
down other tasks when the machine is being used. Related to this, it can
also suppress a lower priority task which would otherwise be using the
processor and that would on a properly written implementation prevent
the machine from shutting down. Yes, some of us do run important
processes at below the default priority because, although it is
important the process runs and runs to completion it is not important
how long it takes. It will also fail on a dual processor machine, or
even a machine with a hyperthreading (of similar) processor like a
couple of the old laptops in my office and a number of our desktop PCs.

(2) You explained why this is "badly" coded. I see one goof-- we're
not detecting time going backwards correctly. Otherwise there are darn
few ways to do a simple histogram. Please feel free to educate me.

I'm not going to bother analysing the wrong code for the job especially
when the right code belongs on another group.

 

[Flash Gordon]

I didnt want to get into the grungy details, but you're right, the code
can be much improved by doing a SetProcessPriority( LOW ). Then the
code not only soaks up less CPU time, it will more accurately reflect
the effects of other running tasks.

But that of course adding calls to change the CPU priority is even less
portable.

So you posted code you knew was wrong without pointing the OP to where
they were likely to get sensible advice? Not the most helpful thing to
do. Anyway, it would still fail abysmally on a number of standard
desktops and notebooks whatever OS they were running and is still the
wrong way to do it when the OS will provide methods of getting the real
information.

 

[Keith Thompson]

I didnt want to get into the grungy details, but you're right, the code
can be much improved by doing a SetProcessPriority( LOW ). Then the
code not only soaks up less CPU time, it will more accurately reflect
the effects of other running tasks.

But that of course adding calls to change the CPU priority is even less
portable.

There is no good portable way to detect CPU idle time.

There is probably a very straightforward system-specific way to do it
in a much less intrusive manner.

This is one of those things that can *almost* be done (but badly) in
portable standard C, but can be done very easily in non-portable C.
And it's not likely that portability would be much of an advantage
here anyway.

To the OP: Try a newsgroup that's specific to your system.

 

[Al Balmer]

Ancient_Hacker wrote On 08/23/06 11:45,:

[...]

Now to figure out if it's idle, that's a bit tricky. But doable, if
your C has a function that returns you the current time, preferably in
small increments. The idea is to form a histogram of the intervals
between the values time() returns, something like:
[the Millikan oil-drop experiment]

This is terrible advice, and badly coded.

Thank you so much for your opinion.

Your opinion would have more weight if:

(1) You had a viable alternative.

That's easy. The OP should ask in a forum where his particular
implementation is discussed. There is a high probability that there's
a better approach than the one you suggested.

 

[ena8t8si]

hi
i have problem to calculate idle time of cpu and if idle time is
more then i have to shut down the system. can anyone tell me the idea
to so that please

You mean if the CPU seems to be idle, you shut it down?

Shutting it down isnt something C can do by itself, but if your C has
the "system"
function, or if you can put the command that runs this program in a
batch file, you're okay.

Just do a system( "shutdown") or put "shutdown" in the batch file,
whatever command shuts down your computer.

Now to figure out if it's idle, that's a bit tricky. But doable, if
your C has a function that returns you the current time, preferably in
small increments. The idea is to form a histogram of the intervals
between the values time() returns, something like:

#include <time.h>

#define MaxMsec 1000

unsigned long int Histo[ MaxMsec ];
int i, j; time_t Now, Prev, Elap, Base;
for( i = 0; i < MaxHisto; i++ ) Histo = 0;

Prev = 0; Base = Prev = time();

for( j = 1; j < 100000; j++ ) {
Now = time() - Base; Elap = Now - Prev; Prev = Now;
If( Elap < 0 ) fprintf( stderr, "Time going backwards!!\n" )
else
If( Elap >= MaxMsec ) Elap = MaxMsec;
Histo[ Elap ] ++;
}

... then scan the histogram. If the CPU is very idle, you should see a
big peak at very low or zero msec. If there are significant other
tasks running, you'll see other peaks, usually in the range of 5 to 50
msec. (Many OS's scheduling algorithms allocate time in slices of 5 to
50 msec).

To be sure, put a loop around that code so it runs for several seconds.

Yes, not guaranteed to work anywhere, but seems to do the job on
Windows and Linux.

You mean, guaranteed not to work anywhere.
At least not if what you're trying to write
in is C.

 

[Richard Bos]

Ancient_Hacker wrote On 08/23/06 11:45,:

Now to figure out if it's idle, that's a bit tricky. But doable, if
your C has a function that returns you the current time, preferably in
small increments. The idea is to form a histogram of the intervals
between the values time() returns, something like:
[the Millikan oil-drop experiment]

This is terrible advice, and badly coded.

Thank you so much for your opinion.

Your opinion would have more weight if:

(1) You had a viable alternative.
(2) You explained why this is "badly" coded. I see one goof-- we're
not detecting time going backwards correctly. Otherwise there are darn
few ways to do a simple histogram. Please feel free to educate me.

Let me add another weightless opinion, then.

Try that CPU-eating hack on any of the systems that I administer, boyo,
and you're going to spend the next few weeks wishing you still had
access to a compiler. Try it twice and you're going to spend more weeks
wishing you still had an account on those computers.

On a more ISO C note: your assumptions about the resolution of time_t
are, to put it mildly, amusing.

Richard

 

[Ancient_Hacker]

Poor Original Poster:

I apologize for my manifold inadequacies, as cheerfully pointed out by
the usual bunch of suspects. Here are some palliative measures:

(1) Several kibitzers pointed out my code would (Horrors) tie up the
CPU for several seconds. Now this would be a semi Bad Thing if all the
following were true:

(a) If CPU time were expensive. Back when I started programming, CPU
time on the CDC 6600 was charged at the rate of 13 cents a CPU second!
Plus 3 cents for every kilo-word second of memory you used. Plus 5
cents for every 1000 disk sectors transferred. Today Sun is willing to
rent you a CPU from their pool for $1 an hour, so this point is no
longer significant.

(b) If (a), and if you didnt realize it is in no way critical to do
this check every second, neigh every minute, if your goal is to power
down the system if it has been idle. By spacing out calls to this
function to once a minute, or even ten minutes, that dilutes the CPU
load to small to negligible proportions. The usual gang of nitpickers
thinks you're too dumb to realize this. I give you a bit more credit.
put a "sleep 60" in the batch file, or a sleep(60)" in your code if
sleep() is available. Problem solved.

(c) If (a) and you didnt realize (b), but you read my suggestion
(*NON PORTABLE*) to lower the CPU priority of this program, either with
a system command see "nice" for Unix-flavored systems, or "start" for
Windows. The adumbrated Helpful Hanks either do not have a good feel
for how OS's can set task priorities, or they're intentionally playing
dumb (they're *very*, *very* awsomely excvellent at this).

(d) And I'm almost wetting my pants as only one nudnik noticed I used
time() which has an awful granularity, and nobody noticed I did the
"time going back" test with an unsigned! time() is portable, but
you'll get much more significant results with some time call that gives
you milliseconds or better.

(e) And unless I missed it, none of these "experts" thought of the
(somewhat arguably) much better way of comparing the elapsed wall-clock
time with the elapsed CPU time. True, you can't always get the elapsed
CPU time (you need a call like cclock() I think, unless there's some
standard way to get the true time used by this program CPU time).

(f) As to the studied grumblers alleged awfulness of this code in the
real world, I seem to recall putting code very much like this into a
custom web server and a web client applications, both of which
satisfied about 200,000 users for over five years.

 

[Eric Sosman]

[...]
(f) As to the studied grumblers alleged awfulness of this code in the
real world, I seem to recall putting code very much like this into a
custom web server and a web client applications, both of which
satisfied about 200,000 users for over five years.

No complaints about the negative array index?

 

[Ancient_Hacker]

Eric Sosman wrote:

No complaints about the negative array index?

oh, right in addition to my other human failings I forgot to put { }'s
around the bottom two statements.

If time every goes backwards, my program will print out "Time going
backwards!", then do something undefined and probably bad.

Add the two {}'s in the obvious place if you ever suspect time will go
backwards AND you still want the program to try to generate valid
results.

And I was also wrong in thinking time_t is always unsigned, so I was in
error in thinking there was an error in calculating negative time
intervals. I think.

 

[Flash Gordon]

Poor Original Poster:

I apologize for my manifold inadequacies, as cheerfully pointed out by
the usual bunch of suspects. Here are some palliative measures:

(f) As to the studied grumblers alleged awfulness of this code in the
real world, I seem to recall putting code very much like this into a
custom web server and a web client applications, both of which
satisfied about 200,000 users for over five years.

Even if all of those are true (and I've had powerful computers maxing
out on processing time, so I would not want a program needlessly wasting
processor time) you have still failed to address:

1) It completely failing on any form of dual processor system where it
happens that there is only one other process eating a significant amount
of time and so that processes is on one processor whilst your detection
code is on the other not being affected by it. Yes, I have had *many*
instances where a *commercial* application was heavily loading one of
the virtual processors on my hyperthreading laptop but everything else
was running find without any interference on the other processor. Your
program would have shut down the notebook in that situation when it was
actually very busy.

2) There are far better implementation specific solutions to this
problem which can actually be made to work properly.

 

[Ancient_Hacker]

1) It completely failing on any form of dual processor system where it
happens that there is only one other process eating a significant amount
of time and so that processes is on one processor whilst your detection
code is on the other not being affected by it.

Righto! But:

(0) Most OS's have more tasks running than they have CPU's. So our hog
task will still get interrupted, especially if it's set to LOW
priority.

(1) It's not going to be an *undetected* problem if the program shuts
off the computer when it thinks things are idle!

(2) That code was written on one of the first dual CPU platforms, a
dual 200MHz Pentium Pro machine (Still running nicely BTW). First
enhancement was to spin off 1, 2, ... 8 threads each doing the cpu
hogging thing. From the results one can usually tell in a portable
manner how many CPU's are in the machine, or at least how many the OS
will give you (on Windows, SetProcessCPUAffinityMask() IIRC.


Regards,

grg

 

[Flash Gordon]

Righto! But:

(0) Most OS's have more tasks running than they have CPU's. So our hog
task will still get interrupted, especially if it's set to LOW
priority.

Depends. If I was to set a long running job going and then walk away on
some of my boxes that would be the *only* task taking significant
processing time.

(1) It's not going to be an *undetected* problem if the program shuts
off the computer when it thinks things are idle!

I would rather not find that the software is faulty through having a
machine shut down when it should not. Especially if it is not required.

(2) That code was written on one of the first dual CPU platforms, a
dual 200MHz Pentium Pro machine (Still running nicely BTW). First
enhancement was to spin off 1, 2, ... 8 threads each doing the cpu
hogging thing.

So you are using at least two system specific routines. Why not actually
ask the OS for the information in a system specific manner since you
*are* doing system specific things anyway?

> From the results one can usually tell in a portable
manner how many CPU's are in the machine,

No you can't. Unless you can point me to the function in the C standard
or even some other standard that Windows, SCO, AIX, IRIX, Linux and
every other OS that is in current use supports. I'll give you a clue,
there isn't one.

> or at least how many the OS
will give you (on Windows, SetProcessCPUAffinityMask() IIRC.

See, you are having to use a system specific call on Windows. So why not
just use a proper system specific solution that does the job *properly*
instead of doing something that tries to use a little standard C to do a
poor job and then has to keep adding more and more system specific stuff
to get around some of the problems?

You are also adding a lot more complexity over what you originally
proposed as the solution to deal with problems you were *already* aware
of. So why post what it seems you *knew* was at the very least an
incomplete solution with out at least telling the OP it was incomplete
and that s/he would have to use various system specific stuff (setting
priority, counting processors, making sure your code really does test
all processors, synchronising across multiple processors, finding out
how many processors and possibly a few other things that I forget) to
get something that actually might work?

I know for a fact you can find out the *real* information because on the
common systems because there are lots of programs that actually report
it. Something that sounds far easier to me. Hell, on *nix it would be
simpler to use system to run one command with the output redirected to a
file and then read that file, or if you want to avoid the security risks
of using a file use the non-standard popen function to run it, then you
are using exactly *two* things beyond the standard instead of many.

 

[Ancient_Hacker]

[ threads non-portable ]

I'm not up on all the latest portability poop, but isnt there something
called "POSIX", and "POSIX-threads?". aka /IEEE 1003/ , ISO/IEC 9945.

Hell, on *nix it would be
simpler to use system to run one command

.... not the best solution, IMHO, as you're adding considerable system
load and page faulting to start up a shell, which will start up "who"
or "top". Adding two more processes and load to the mix might
obfuscate just what we want to know. Not to mention running any
system command is non portable, which somehow is okay for you to
blithely do, but gets my butt kicked around in an infinite loop.

How's about we try to focus on intelligently answering the OP's
question, instead of trying to convince each other what *has* been done
can't be done to some particular level of purity?