By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,680 Members | 1,436 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,680 IT Pros & Developers. It's quick & easy.

calculation of cpu idle time

P: n/a
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

Aug 23 '06 #1
Share this Question
Share on Google+
33 Replies


P: n/a

ra******@gmail.com wrote:
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[i] = 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.

Aug 23 '06 #2

P: n/a


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.

--
Er*********@sun.com

Aug 23 '06 #3

P: n/a

Eric Sosman wrote:
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.

--
Er*********@sun.com
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.

Aug 23 '06 #4

P: n/a


Ancient_Hacker wrote On 08/23/06 12:47,:
Eric Sosman wrote:
>>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.

--
Er*********@sun.com


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.

--
Er*********@sun.com

Aug 23 '06 #5

P: n/a
"Ancient_Hacker" <gr**@comcast.netwrites:
Eric Sosman wrote:
>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.
--
"A lesson for us all: Even in trivia there are traps."
--Eric Sosman
Aug 23 '06 #6

P: n/a

Ben Pfaff wrote:
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.

Aug 23 '06 #7

P: n/a
Ancient_Hacker wrote:
Eric Sosman wrote:
>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.

--
Er*********@sun.com

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.
Aug 23 '06 #8

P: n/a
"Ancient_Hacker" <gr**@comcast.netwrites:
Ben Pfaff wrote:
>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.
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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Aug 23 '06 #9

P: n/a
Ancient_Hacker wrote:
Ben Pfaff wrote:
>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.
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.
--
Flash Gordon.
Aug 23 '06 #10

P: n/a
On 23 Aug 2006 09:47:09 -0700, "Ancient_Hacker" <gr**@comcast.net>
wrote:
>
Eric Sosman wrote:
>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.

--
Er*********@sun.com

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.
>(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.
--
Al Balmer
Sun City, AZ
Aug 23 '06 #11

P: n/a

Ancient_Hacker wrote:
ra******@gmail.com wrote:
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[i] = 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.

Aug 24 '06 #12

P: n/a
"Ancient_Hacker" <gr**@comcast.netwrote:
Eric Sosman wrote:
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
Aug 24 '06 #13

P: n/a
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.

Aug 24 '06 #14

P: n/a
Ancient_Hacker wrote:
[...]
(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?

--
Eric Sosman
es*****@acm-dot-org.invalid

Aug 24 '06 #15

P: n/a

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.

Aug 24 '06 #16

P: n/a
Ancient_Hacker wrote:
Poor Original Poster:

I apologize for my manifold inadequacies, as cheerfully pointed out by
the usual bunch of suspects. Here are some palliative measures:
<snip excuses for poor code>
(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.
--
Flash Gordon
With a hyperthreading notebook that cost about 1000UKP over 2 years ago.
Aug 24 '06 #17

P: n/a

Flash Gordon wrote:
Ancient_Hacker wrote:
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) 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

Aug 24 '06 #18

P: n/a
Ancient_Hacker wrote:
Flash Gordon wrote:
>Ancient_Hacker wrote:
>>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) 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.
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.
--
Flash Gordon
Aug 25 '06 #19

P: n/a

Flash Gordon wrote:
[ 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?

Aug 25 '06 #20

P: n/a
Ancient_Hacker wrote:
Flash Gordon wrote:
> [ 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.
Yes, but that is off topic here. Try comp.unix.programmer, where
they are topical. Here we limit discussion to the language as
specified in the ISO standards, or the previous K&R
quasi-standard. That way everybody knows just what we are talking
about.

--
Chuck F (cb********@yahoo.com) (cb********@maineline.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.netUSE maineline address!
Aug 25 '06 #21

P: n/a
Ancient_Hacker wrote:
Flash Gordon wrote:
> [ 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.
That is only to POSIX systems. The last time I checked, which was using
the current versions of Windows and my subscription to MSDN which
provides the latest compiler version etc, POSIX threads were not part of
Windows.
> 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.
Just before the bit you left in I said:
| 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.

The implication I was making, which you seem to have missed, was that
you can do what I have stated more than once in this thread and use some
system specific routine to do it. The bit you left in was just a silly
example showing that it can be done with far less code than the masses
that you are ending up with.

I stated my solution was not portable. Yours was not portable yet you
keep trying to claim it is. It also has the one and only advantage I
claim for it, being far simpler than yours to implement and using far
less system specific routines.
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?
I have already answered that more than once. Ask in a system specific
group for the correct system specific way to get the information.

To repeat the point you are continuing to fail to address and snipped
from my last post:
| 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

Especially since once you have added in all the other system specific
bits to get your solution close to working required at least half a
dozen system specific things.

I honestly can't understand why you think that anything other than
asking the OS for the CPU utilisation would be appropriate when the OS
can give you accurate information with the overhead of a single hook to
the OS + any initial one off setup it requires. Any other method will be
less accurate, more complex (as illustrated by your attempts to work
around all of the problems I've raised with you "solution" not all of
which you've addressed"), requires more code, will waist more processing
time, and be less efficient by any measure I can think of.

I really cannot think why, having had it pointed out to you that it is
possible to ask the OS for the information, you cannot accept it as a
vastly superior solution.

No, I'm not going to post the solution here because it would not be
properly vetted. I've just looked up in the MS documentation to prove to
myself (not you) that I am correct in what I've said all along that
there is a proper system specific solution.

Now, unless you are going to address this point I've raised repeatedly
I'll just file you under the category of troll and only respond to you
where required to point out that you are giving bad advice if others
have not beaten me to it.
--
Flash Gordon
Aug 25 '06 #22

P: n/a
Flash, perhaps a better moniker for you would be "Pollyanna".

It is to josh to think you can believe everything an OS tells you.

Try asking Windows what audio or video codecs it has, what rates they
support, and how amenable they are to rate conversion, interlacing,
motion compensation, and more. Yep, you'll get answers.

Generally unreliable answers. It seems in the real world one should
actually *request* a codec and try hooking it up a particlar rate,
format, endinaness, and only then do you have a clue whether the codec
can actually do what Windows says it can.

Ask the OS for how much memory there is. Yep, you'll get a number
back. Believe it, and you can get into a world of hurt.

Ask an OS how many CPU's it has. Yep, you'll get a number back.
Believe it, and your users may wonder why your programs run so slowly,
or not at all.

(for those of you that havent gotten the drift-- reality is quite often
considerably different from what is advertised) The number of CPU's is
only vaguely related to the number of CPU's that will be available to
your program. Perhaps a device driver has reserved CPU1 to speed up
disk compression. Perhaps it's kind and releases CPU1 when it's done,
perhaps not. Perhaps CPU2 is on the other side of the NorthBridge, and
can never be assigned to tasks below 0x800000. Perhaps CPU3 was
available the last time the OS counted CPU's, but is currently off-line
due to a double bus fault. Lots of things can happen between the time
a CPU-counting routine stored a "2" somewhere, and several gazillion
CPU cycles later.

If Windows tells you there are 3GB of memory available, beleive it at
your own risk. Some of that memory, up to a third, is actually tied
up by the disk cache. Try using that memory and all of a sudden all
the desktop icons take 5-10 seconds to refresh. Folder listing windows
go blank or take 10 to 200 seconds to update. Another third may be
virtual, and instead of memory being just 3nsecs away, it takes
300,000,000 nsec. Ouch. But Windows said it was "memory".

( I've found all these things out, the hard way ).

Aug 25 '06 #23

P: n/a
Ancient_Hacker wrote:
Flash, perhaps a better moniker for you would be "Pollyanna".
<snip>
Ask the OS for how much memory there is. Yep, you'll get a number
back. Believe it, and you can get into a world of hurt.
Only if you ask it the wrong question or for the wrong reason. If you
want to know how much physical memory, ask that, if you want to know how
much is available for you program, ask that etc.
Ask an OS how many CPU's it has. Yep, you'll get a number back.
Believe it, and your users may wonder why your programs run so slowly,
or not at all.

(for those of you that havent gotten the drift-- reality is quite often
considerably different from what is advertised) The number of CPU's is
only vaguely related to the number of CPU's that will be available to
your program. Perhaps a device driver has reserved CPU1 to speed up
disk compression. Perhaps it's kind and releases CPU1 when it's done,
perhaps not. Perhaps CPU2 is on the other side of the NorthBridge, and
can never be assigned to tasks below 0x800000.
If you want to know the number of processors available to your task, you
ask that, *not* how many processors the system has. You also ask further
questions to determine if they are all real or whether it is
hyperthreading if that matter.
Perhaps CPU3 was
available the last time the OS counted CPU's, but is currently off-line
due to a double bus fault. Lots of things can happen between the time
a CPU-counting routine stored a "2" somewhere, and several gazillion
CPU cycles later.
That can happen if you use the sort of stupid trick you are advocating
as well so it is a completely irrelevant argument.
If Windows tells you there are 3GB of memory available, beleive it at
your own risk. Some of that memory, up to a third, is actually tied
up by the disk cache. Try using that memory and all of a sudden all
the desktop icons take 5-10 seconds to refresh. Folder listing windows
go blank or take 10 to 200 seconds to update. Another third may be
virtual, and instead of memory being just 3nsecs away, it takes
300,000,000 nsec. Ouch. But Windows said it was "memory".

( I've found all these things out, the hard way ).
Then you have been asking it the wrong questions. If you want to know
the resources available to your program then that is the question you
ask, not the total amount of resources. Getting the wrong answer for
asking the wrong question is not a reason for not asking the correct
question. Getting back to the topic, the fact that programs exist that
*actually* report CPU usage *proves* that there is a system specific
method to get that information. Since it exists there is no good reason
to used some half assed method to try to guess what is going on.

I've replied since you did actually make an attempt to answer the point.
Although as you should know by now you should have provided context.

I will stop this now since I'm sure the rest of the people here are
bored with it. I'll just make the final point that the original
redirections by others and myself to system specific groups were the
correct thing, since there one will find people who know what functions
are available and whether they really answer the question at hand. Doing
as you did and posting what you have since claimed you *knew* was a long
way from being a complete solution with no warnings and no redirection
to an appropriate group was exceedingly unhelpful since the OP could try
to just go ahead and use it, find it works on his test machine, but then
fails when put on the intended machine because of any of the
possibilities already suggested or something else.
--
Flash Gordon
Aug 25 '06 #24

P: n/a
On 25 Aug 2006 03:57:07 -0700, "Ancient_Hacker" <gr**@comcast.net>
wrote:
>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?
The OP's question was properly answered long ago - find the proper
forum and ask there.

--
Al Balmer
Sun City, AZ
Aug 25 '06 #25

P: n/a
Flash Gordon wrote:
The last time I checked, which was using
the current versions of Windows and my subscription to MSDN which
provides the latest compiler version etc, POSIX threads were not part of
Windows.
Look again. I'll wait. ....... Meanwhile I google for "Windows Posix
threads, and get a pageful of hits)....

No, I'm not going to post the solution here because it would not be
properly vetted. I've just looked up in the MS documentation to prove to
myself (not you) that I am correct in what I've said all along that
there is a proper system specific solution.
Oh, Polly, please stop, my ribs, they ache.

Apparently you and your ilk think you can have it *three* ways:

(1) This subject the Solons think is somehow non-portable, so it not
suitable for discussion here.

(2) But, anyway, A_H's, solution (,while portable, and has been running
in production for years, unspecifiedly (somehow) stinks, and no
elaboration will be forthcoming. (One suspects, they're mortified the
double-domed regulars didnt think of it first).

(3) And, thirdly, I, Pollyanna, propose a better solution, which is
non-portable violating (#1) , and I'm not going to expicitly cite its
name, or show a test program, but I assure you it's the best possible
solution on this, the best possible of all SunnyBrook Farms.
(: Oh, the anti-hutzpah googles, they do nothing! :)

Aug 26 '06 #26

P: n/a
[snips]

On Thu, 24 Aug 2006 04:20:21 -0700, Ancient_Hacker wrote:
(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.
If you're sucking up cycles completely pointlessly, it's not the CPU time
that matters - it's the time of all the _people_ using the machine who are
now getting less efficient processing thanks to your sloppy code.

It's like this: air is free. However, some goober's tying up supply
lines, so if you could kindly hold your breath for an hour or so, we'll
get you your next allotment then.
(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.
Since there are vastly better ways, not least of which is to simply use
OS-provided services, available in most (desktop-class, at least) OSen,
ways which don't suck up pointless cycles, ways which don't require giving
every Tom, Dick and Harry access to a Shutdown routine, ways which can
actually account for other users without getting confused by wall clock
versus CPU cycles and that sort of thing, why not use those?
(c) If (a) and you didnt realize (b), but you read my suggestion (*NON
PORTABLE*)
The entire notion of being able to shut down through code is non-portable.
(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.
Which is also non-portable.
(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.
Is that elapsed CPU time for the system, the process, the user, or
something else? How do you tell? And, again, you can't even get this
information portably.

All in all, a pretty half-assed approach.

Aug 27 '06 #27

P: n/a
On Fri, 25 Aug 2006 03:57:07 -0700, Ancient_Hacker wrote:
>
Flash Gordon wrote:
> [ 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.
Yes there is. There's also something called "C", which is what gets
discussed here.
Aug 27 '06 #28

P: n/a
[snips]

On Thu, 24 Aug 2006 09:37:56 -0700, Ancient_Hacker wrote:
>
(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.
Not the point. I have one CPU running 99%. I have another three, each
running close to zero usage. If you're on one of the low-use three,
you'll see very low utilization, think the system is idle, and shut it
down - and the other process will be *most* unhappy. As will I. As will
you, when I come after you with a baseball bat for shutting down a system
that's busy doing actual real stuff.

Actually, you wouldn't shut it down - you'd have no permissions to do so,
and wouldn't get 'em without some demonstration of a _little_ more
comprehension of multiprocessor architectures, but that's another matter.
Aug 27 '06 #29

P: n/a

Kelsey Bjarnason wrote:
[snips]

On Thu, 24 Aug 2006 09:37:56 -0700, Ancient_Hacker wrote:

(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.

Not the point. I have one CPU running 99%. I have another three, each
running close to zero usage. If you're on one of the low-use three,
you'll see very low utilization, think the system is idle, and shut it
down - and the other process will be *most* unhappy. As will I. As will
you, when I come after you with a baseball bat for shutting down a system
that's busy doing actual real stuff.

Actually, you wouldn't shut it down - you'd have no permissions to do so,
and wouldn't get 'em without some demonstration of a _little_ more
comprehension of multiprocessor architectures, but that's another matter.
Perhaps you missed my earlier replies, where I amplified the answer
which covers the multi-CPU case. I wrote the code specifically for an
ancient 200MHz micron dual Pentium Pro machine, oh, 8 years ago. Works
perfectly.

Aug 28 '06 #30

P: n/a
[snips]

On Mon, 28 Aug 2006 09:14:40 -0700, Ancient_Hacker wrote:
Perhaps you missed my earlier replies, where I amplified the answer which
covers the multi-CPU case. I wrote the code specifically for an ancient
200MHz micron dual Pentium Pro machine, oh, 8 years ago. Works perfectly.
Long as it *stays* on an ancient 200Mhz PPro, that's fine. Loose it in
the world at large, it's virtually guaranteed to be doing the Wrong Thing.
Aug 29 '06 #31

P: n/a

Kelsey Bjarnason wrote:
[snips]

On Mon, 28 Aug 2006 09:14:40 -0700, Ancient_Hacker wrote:
Perhaps you missed my earlier replies, where I amplified the answer which
covers the multi-CPU case. I wrote the code specifically for an ancient
200MHz micron dual Pentium Pro machine, oh, 8 years ago. Works perfectly.

Long as it *stays* on an ancient 200Mhz PPro, that's fine. Loose it in
the world at large, it's virtually guaranteed to be doing the Wrong Thing.
Uh, no, it was developed there, deployed worldwide. Got a huge raise
as a result.
Not a single SPR about that code.

Aug 29 '06 #32

P: n/a

Ancient_Hacker wrote:
Kelsey Bjarnason wrote:
[snips]

On Thu, 24 Aug 2006 09:37:56 -0700, Ancient_Hacker wrote:
>
(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.
Not the point. I have one CPU running 99%. I have another three, each
running close to zero usage. If you're on one of the low-use three,
you'll see very low utilization, think the system is idle, and shut it
down - and the other process will be *most* unhappy. As will I. As will
you, when I come after you with a baseball bat for shutting down a system
that's busy doing actual real stuff.

Actually, you wouldn't shut it down - you'd have no permissions to do so,
and wouldn't get 'em without some demonstration of a _little_ more
comprehension of multiprocessor architectures, but that's another matter.

Perhaps you missed my earlier replies, where I amplified the answer
which covers the multi-CPU case. I wrote the code specifically for an
ancient 200MHz micron dual Pentium Pro machine, oh, 8 years ago. Works
perfectly.
Maybe. All we know is that you have not had any complaints about the
code.
If, as seems likely, the code is used to set tuning parameters for
execution speed,
as long as the values returned are reasonable there will be no
complaints.

More importantly, this is a hack. An approach that will give, perhaps,
the correct results in a specific environment (hacks can of course be
clever and useful, but their limitations should not be ignored).
It is always dangerous to try to genealize a hack (especially, and
in this case your comments on posix threads make this clear, when
you have no idea what you are doing). With a little effort, this
approach
could be the basis of a very nice utility which gives a
a reasonable answer as to what resources are available to a process,
however it should not be used to try to determine the idle time.

-William Hughes

P.S. A 200 MHz multi-CPU machine is modern.

Aug 29 '06 #33

P: n/a
William Hughes wrote:
P.S. A 200 MHz multi-CPU machine is modern.
I have a Dual PPro IBM machine from the 20th Century.

Bought it at a yard sale with a 4-Processor HP, because they were SMP
boards but more because each had a 4mm tape drive. One benchmark for
"ancient" is applied whenever computer hardware is obtained from a
dumpster or yard sale :-)
Aug 29 '06 #34

This discussion thread is closed

Replies have been disabled for this discussion.