'top' disagrees with CPU Monitor


Do not read this sign.
Often when CPU Monitor shows my CPU utilization as maxed out, 'top' in a Terminal window shows very little usage in the %CPU column. Anyone have an idea why?

I am assuming they are monitoring separate proccesses for some reason, ie CPU monitor displaying actual CPU use with regards to GUI activity and all, whereas top might only be showing background proccesses. Its only a guess, I am probably wrong. I will check out my computer when i get home!

The command "top" is ALWAYS going to be more accurate than CPU Monitor because it sees EVERYTHING running in the ENTIRE operating system (daemons, every background process and of course the GUI).

I know that this doesn't answer why CPU Monitor is showing near max, but it's obviously inaccurate.
You are not comparing apples to apples (ahem) here. While both will monitor and display a % of CPU usage, obviously both do things differently to display that info. CPU monitor has to generate all the fancy flashing lights and stuff in the GUI (and that takes more effort. But this is only momentary so while you may have a terminal window open with top running, if it doesn't catch the update at the moment when CPU monitor makes its adjustment it shows a lower useage.

You can adjust the top timed output by using the -s flag [i.e. top -s 5 ] for 5 seconds between updates the default is 1 second. You can see similiar data in ProcessViewer, it is only a little more graphical than top.

This is why Mac OS X is so awsome, now you can use the light weight non-graphical "power" applications to great advantage and still have all sorts of GUI things to help you out (as much as I liked Linux, this beats it by a mile).

Basically, as grbear said, top is more accurate as it displays actual numbers and does not need to generate graphics to display that info. But watchin the CPU monitor is fun and using ProcessViewer is easssyyy.
Or another thought occured to me--maybe your system has been hacked and the top command was replaced with a broken one that hides the hack. And CPUmonitor is actually telling the truth.

The way to know more certainly, is if your network connection is also maxed out (somebodies using that CPU somewhere).

This happend to a friend of mine on his linux system. The hack/crack replaced a whole bunch of the *nix commands with broken ones that would hide the presence of the cracker.

Sorry, if this scares you in any way-- it is most likely just the graphical stuff. But if your system and network connection are constantly pegged out then there might be something more. Could also be a runaway GUI app.
Does top show kernel usage? Maybe that's it. I notice that top and CPU Monitor differ most when there's a lot of disk access (like when compiling something). Maybe CPU Monitor captures the effort of reading and writing to the disk in some kernel (extension?).

OK, now I know what you are looking at.

First, yes-- top shows the kernel usage--it shows everything.

If you are watching CPU monitor during a compile and you are looking at the list of items in top. It appears as though the processes are not doing much and certainly don't add up to what the CPU monitor is showing.

However if you look at the top of 'top'-- on the second line of header info, you will see something like--

CPU usage: 6.1% user, 10.6% sys, 83.3% idle

When you are compiling or doing anything that uses the CPU you will notice that 'user' and 'system' added together will equal what CPU monitor displays (or be pretty close)i.e. it well be maxed out. Again synchronization between the two may not be precise.

So even though the individual list of items in top don't seem to add up, there can be many more that don't appear because they are below the screen. Using the -u flag with top will sort by CPU usage with the big CPU usage listed first. Interestingly , that puts top at the top on my work system.

For other top options, type 'man top' in a terminal window.
Thanks, jimfl. We're getting closer to an answer, but I always use -u, and still, things don't add up. But I think we may have stumbled onto something: the list of processes is just that--processes. I don't think it counts kernel time.