calculation of cpu idle time

[CBFalconer]

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

 

[Flash Gordon]

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

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

 

[Ancient_Hacker]

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

 

[Flash Gordon]

Flash, perhaps a better moniker for you would be "Pollyanna".

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.

 

[Al Balmer]

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.

 

[Ancient_Hacker]

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!

 

[Kelsey Bjarnason]

[snips]

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

 

[Kelsey Bjarnason]

[snips]

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

 

[Kelsey Bjarnason]

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

 

[Ancient_Hacker]

[snips]

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

 

[Kelsey Bjarnason]

[snips]

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.

 

[Ancient_Hacker]

[snips]

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.

 

[William Hughes]

[snips]

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

 

[jmcgill]

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