I find Task Manager Interesting

Open TaskManager
Set it on the Performance Tab
Just do nothing for a bit and just watch it.

Then do other things and watch it.

On my Machine something is using 34% of the CPU every 12-15 seconds.

At the bottom of the Processes Tab is System Idle Process. That changes from 99% to 66% and back which seems to correspond with the CPU Usage Meter.

I messed around and opened a couple of other things. WMP was one. A card Games was another. I was playing .MID file

I did something that drove the meter to 100% NOTHING did ANYTHING till the meter dropped back.

Now. I am THINKING. That this is what happens to cause a machine to lockup when we get too many things running. Too many instructions at once.

Many times we blame RAM. But is RAM really always to blame for it all ? I myself question that now.

BillyBob

PS.
Submitting this takes 35% of the CPU.

BB

 

I tend to agree with Steve.

This can be a point, where there are so many asynchronous processes contending for the processor (on a really busy box) that you will notice sluggishness on one of your programs, but a PC will not hang because there are "too many instructions at once ".

The idle process is exactly that. A process that "consumes" CPU cycles when the processor is idle (doing nothing).

If you want to see what is actually using the CPU, use the Processes tab, and click twice on the word CPU. This will sort the display by CPU % descending. That is, the one(s) consuming the most will be at the top.

 

That may well be.

But used and over-used are two different things I believe.

As I mentioned all was OK untill the meter hit 100% then it hung up.

33%+40% =73%. Add another 33% like that System Idle Process that I show, and you got 106%. 106%=Lockup time I believe If they should all happen to kick in at the same time .

Left click = 2%
Right Click= 8-9%
Scroll With wheel= 8% - 12%. Depends I guess on what you are scrolling. Within this note it was only 6-8%. Scrolling the full window it was 10-18%.

BillyBob

 

OK I must admit that I do not understand that at all. All of those processes are supposed to be loaded I agree. But IF THEY are using the CPU how come it is at 0% ?

Are they in the CPU or RAM. And do not effect the CPU untill used.

Outside of that System Idle process the CPU sits at 0% until I do something.

OR.
Are they in the Page File which shows as 179meg being used ?

I got a 5 year old begging me to go outside so I will be back later. ( I am baby sitting this week )

BillyBob

 

A PC should NOT be hanging when the processor reaches 100%!

BUT, if you have a misbehaved application that is "soaking" the CPU to the point that another application running at the same priority, requires the CPU, then that application will appear to be hung.

"IF THEY are using the CPU how come it is at 0% ? "
If the percentage is zero then they are NOT using the CPU.

"Are they in the CPU or RAM. And do not effect the CPU untill used. "
They are in RAM and potentially the pagefile, and don't affect the CPU until THEY need to do something. Either on their own (such as an internet connection) or as a result of user input.

"Outside of that System Idle process the CPU sits at 0% until I do something. "
Which is what a normal system will look like.

"Are they in the Page File which shows as 179meg being used ? "
Pieces of some of them obviously are.

 

This is getting to be quite interesting to sit here and watch both the page file and the Random Access Memory change as I do things.

And why things happen if I should get too much running.

I just shut off Windows Autoupdate. ( got the notice about not being a good idea of course. )

But the PF usage went from 179 MB to 165 MB. ( one item 14MB ??? WOW )

At least I now have a better idea of what happens when I do what.

MAYBE !! LOL

BillyBob

 

You hit the nail on the head! Having had Norton's 'CPU use' monitor on my desktop for years, I've seen many lockups at 100% CPU use, and there's a simple explanation.

There are basically two types of "crash ": a program jump to a data area rather than to CPU instructions, and a closed loop, a program snippet that jumps to its beginning eternally unless you shut off the power to it or, preferably, force a jump to 0 with a reset button. Both are caused by erroneous (bad) programs.

A jump to data, which are treated as if they were CPU instructions, but of course aren't, locks up because there's no way to get back to the instruction stream at the right place for the program to carry on. This may or may not cause a 100% use of the CPU, but of course the endless loop does.

The CPU handles instructions linearly, one after the other, hyperthreading or not. It's the speed at which it can be switched between programs that gives the appearance of multitasking. Lockups or crashes occur only when an error has occurred, never because too many instructions are sent to the CPU.

 

I have to disagree.

A poorly written program that somehow manages to try to execute data won't hang. The processor is smart enough to know that what it is attempting to execute failed, and the result will be a fatal exeception of some ilk. Or, on XP a STOP type exeception.

The "lockups" at 100% can occur when a higher priority process(s) is consuming all of the available processor, thus leaving none for lower priority apps. This makes it appear that the lower priority application/process has hung.

And, instructions are not executed linearly, especially on a HT'ed processor.
The HT technology allows instruction paths to be executed in parallel.

 

Maybe not. I didn't say it did! I said it crashes, which it does, a crash being defined as an inability of the machine to do further useful work, requiring a reset of the program counter to 0 either by a hardware or software reset or a power off and on.

Wrong. The P4 or AMD-XP processor is stupid; the smarts you describe come from the programming, the operating system, and result from the program labeling the data and instruction containing areas of memory so that it can prevent execution and present the "stop" screen to the user to try to explain why execution failed. If execution isn't stopped prior to the jump to data, the program and processor are helpless. I have seen plenty of crashes without any STOP screen or BSOD.

If you're fortunate enough to run an AMD64, that processor sets a bit to indicate where the next instruction comes from and the software may read the bit and take appropriate action. That's not smart, it's information for the OS to use or not as it sees fit.

If you just wait, the "lockup" will often resolve itself. If so, that's not a crash. If not, then it is. It's bad programming in any event.

Not really. Hyperthtreading involves emulation of dual processor systems by using two virtual (= imaginary) processors. It does minimally improve thru-put when multitasking, but not anywhere comparable to a two processor system. You're still running a single processor, but adding a few instruction codes from a second program to fill some empty slots in the flow of code thru the processor. That's quite different from two processors and not much more efficient than not using hyperthreading. That's why AMD hasn't bothered, but rather opted for the two processors on a die option, which does approach the thru-put of a two processor system, according to benchmarks.

 

"Wrong. The P4 or AMD-XP processor is stupid; the smarts you describe come from the programming, the operating system, and result from the program labeling the data and instruction containing areas of memory so that it can prevent execution and present the "stop" screen to the user to try to explain why execution failed. If execution isn't stopped prior to the jump to data, the program and processor are helpless. I have seen plenty of crashes without any STOP screen or BSOD. "

Ok. Idle question(s)/observations.

Given that
1. The design spec for the processor defines what an instruction opcode can look like (ie: the various formats)
2. For each "valid" opcode that is decoded, it verifies what a valid parameter(s) to the opcode contains (and if they aren't valid, there are defined exceptions that the hardware generates that the OS can act on)

it would appear that the "smarts" to detect whether or not it is a properly defined instruction is in the CPU with inconsistencies being fed back to the OS via hardware interrupts/exceptions.

For example, if the CPU attempts to execute a 64bit instruction, it will fail with an "Invalid Opcode" exception.
Or, if a memory operand is outside the bounds, a General Protection exception will be generated.

As for HT, my comment was in response to your linear comment.
And, AFAIK (virtual CPUs or not), an HT processor is processing instructions in parallel.

 

WhitPhil,

The problem with CPU generated exceptions based on op-codes is there are so many op-codes and many don't need parameters. If you've ever examined assembler codes with a debugger and looked at data the same way, you've seen nothing but valid op-codes (taken individually, but of course the flow is meaningless). That's why the emphasis today is on marking the locations of code and data in memory in an effort to avoid jumping into data. That's the point of software data execution prevention (dep) in SP2, which you can optin or optout in boot.ini. That's also the reason for the amd64 indicating where the next instruction comes from, referred to as hardware dep.

With respect to HT, you win. I only wish to emphasize that it's mainly a marketing ploy of little to no practical value. Decoding two threads at once requires compliant software, and most users don't have that anyway.

 

But what DEP is attempting to do, is stop valid executable instructions from being run, from what has been classified as a Data area. Ie: Code is not supposed to be there. I don't "think" it's intent was to stop accidental jumps to a data area (which it will obvsiously detect, if that option has been enabled).

This is different than what we were discussing (I think). Which was the attempt by a processor to execute "invalid" instructions. (in the case of DEP it is attempting to stop "valid" instructions from being executed.

As for CPU generated exceptions, I think they are here to stay.

 

Yes, I think the name says it all: data execution prevention. In my experience the CPU interprets data as valid instructions. That causes a crash as I described above. The software must, if possible, prevent those op-codes from being run by preventing the program counter from pointing (=jumping) to data. The processor by itself is NOT intelligent enough to do that, not even the amd64 which can warn the software but take no action itself; hence the need for DEP (or better programming ).

 

sparrow and WhitPhil . Is what your saying to us who just every day user's is don't/no need to buy a 64 bit CPU and if the PC Hangs at 100% for to long Reboot , as well as keep our running process as low as possibile ?

Thanks purplemtn

 

Hi purplemtn

Most users don't need to bother about what we're talking about. MS has done the worrying for us and developed the features that keep us out of trouble most of the time. We haven't mentioned the prevention of running virus code which MS mentions in its description of dep. Personally, I find some of the side effects or inclusions in dep to be obnoxious, such as crippling explorer by causing 'illegal operation' shutdowns of the program, preventing me from using my computer as I see fit, so I disable it on computers I deal with. We've been getting by without it for years, and yes, we reboot when necessary to keep going. That’s no big deal if you make sure to back up your work as you go along. Rebooting really isn't a frequent occurrence, maybe once or twice a month for me.

I don't limit the processes running; I usually have 6 or more programs at a time in addition to the many 'threads' windows keeps going, sometimes well over 100. Multitasking is the name of the game and is what windows is designed to do.

The 64 bit CPU is the wave of the future, but to buy one now is, IMHO, not cost effective, since there's not much software available for 64 bits and so it just runs in 32 bit mode.

 

sparrow

As far as I can determine, the reason that DEP is implemented in SP2 and is part of the AMD and Intel processor line, is to provide another level of protection against buffer overflows, which allows virus writers to take advantage of this "feature ", and embed executable code that gets run as a result.
So, the Data Execution Prevention is not preventing Data from being executed, but rather preventing executable statements from being processed from an area defined to be only containing data.

It is not an attempt to stop processors from accidentally running "data ". And, as I pointed out above, the design specs of the cpus have specific exceptions which will occur, when an opcode is either not defined, does not have the correct parameters or the content of the parameters are invalid.

purplemtn
If you have processes that are consuming 100% of the CPU AND are causing the PC to hang, you need to determine what that process is and then work towards a resolution. It could be shoddy programming or you have malware running in the background that is masking the problem.

As for keeping processes to a minimum, I agree with sparrow.
Unless you have a slower cpu and are memory constrained, fill it up and run it to the hilt. The capacity is there to be used.

 

Really? I don't think the experts misnamed DEP.

That's what I'm saying. The CPU looks at ram and interprets the bits it sees as op-codes and executes them. If you'd bother to look at data with a debugger you'll see nothing but op-codes, which is just what the CPU sees. Been there, done that; it's part of programming in assembler.